Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Stored versus in-memory IProperty instances(was:IdAS is now Java 1.4)

Yeah, we were just talking about this here as well.  Right now, when you need to update an element within a ComplexValue, you would have to get an IAttribute with the (entire) value as it exists, and then you would need one with the (entire) value as you want it to be.  Then you send these in to updateSubject (the old as an UpdateOperation.DELETE, and the new as an UpdateOperation.ADD).
 
Yeah, this is cumbersome.  It would be nice if we could get the instance of the value and drill right down to the element that we need to change...  The obvious way to allow that to happen is to re-introduce the ability to perform updates directly to values.  But then we're back to the problem of not knowing what attribute/value instances are associated to a "real" object and which are not. 
 
There's also the thought that all updates should only be applied to the instances in memory, and that we add a "commitUpdates" operation.  This would require CPs to keep track of a lot more state than they do today.
 
Gotta run, I'll keep thinking.
 
Jim

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 3/29/07 8:03 AM >>>
Jim,
 
> I think it's too confusing to the IdAS consumer (and will also require state tracking by the CP) to have two semantics
> associated with the same method based on how the object was originally obtained.  I would rather see setValue only affect > the in-memory copy of the Attribute.
 
In the previous IdAS model we didn't have any "in-memory" Attribute. We were able to get an instance of Attribute only by calling getAttribute() or creatingAttribute() of IDigitalSubject (however ComplexValue could be able to be as "in-memory" as "stored"). I am agree this ambiguity is not good. On the other hand, supose that DigitalSubject has some attribute which contain a list of ComplexValue, and we need to change only one property of some of these complex values. How it should be performed using new model?
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Wednesday, March 28, 2007 7:41 PM
Subject: Re: [higgins-dev] Stored versus in-memory IProperty instances(was:IdAS is now Java 1.4)

I think we're getting somewhere here.  I agree with all the views you have in this reply except one...
 
>2. Attibute was returned by IDigitalSubject.getAttribute(). In this case it
>is "stored" attribute and its value should be changed.
I think it's too confusing to the IdAS consumer (and will also require state tracking by the CP) to have two semantics associated with the same method based on how the object was originally obtained.  I would rather see setValue only affect the in-memory copy of the Attribute. 
 
In other words, think of IAttribute's returned by IDigitalSubject.getAttribute as returned by value rather than returned by reference (which would be more symmetric with the way you propose we think of IAttributes which are passed to IContext.addSubject).  If we do this, the semantics of an IAttribute instance remain consistent.
 
In fact, it was this very issue which led me to push all build and update methods to IContext and off of the specific objects.  There was nothing to indicate to the IdAS consumer when an update would actually change something in a backing data store.  For example, a complex application might have a function which takes an IAttribute and at some point might call setValue on it.  That function might not know how the IAttribute was obtained.
 
The only argument I see against this is one of convenience to the IdAS consumer.  Let's se what it would take to update an attribute once it has been gotten from a subject:
IAttribute attr = myDigitalSubject.getAttribute(<some attr type>, null);
attr.setValue(<args>);
Vector v = new Vector();
v.add(new UpdateOperation(UpdateOperation.UPDATE_OP_ADD, attr));
myContext.updateSubject(<subjectID>, v.iterator());
 
There are a number of ways to make the 3 lines of code easier.  We could overload updateSubject to take a single UpdateOperation (but there is another thread asking that we discontinue overloading). We could add more methods like IContext.updateAddAttribute(String cuid, IAttribute attr) which are really just shortcuts for the three lines above, but then we get method bloat.  I'm not sure those 3 lines of code are that bad.
What do you think?
 
Jim
 

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 3/28/07 8:49 AM >>>
Jim,

> // Next, I assume all would agree that this would add the entire
> myAttribute to mySubject2
> Vector v = new Vector();
> v.add(myAttribute);
> String s = myContext.addSubject("http://...#person", "mySubject2", v,
> null);

I think we should consider myAttribute as a parameter by value not by
reference. For mySubject2 we should create its own attribute instance, not
just set a reference to myAttribute. So there should not be any two
DigitalSubjects which have a reference to the same attribute/value instance.

> // Next, I assume all would agree that this would add the entire
> myAttribute to mySubject2
> Vector v = new Vector();
> v.add(myAttribute);
> String s = myContext.addSubject("http://...#person", "mySubject2", v,
> null);
> // Here's where I'm confused.  Does this affect mySubject1, mySubjet2,
> both, or neither?
> myAttribute.setValue(buildSimpleValue("http://www.w3.org/2001/XMLSchema/normalizedString","brown"));

I think we should separate two possible situations:

1. Attribute is "in-memory" instance created by IContext.buildAttribute().
In this case IAttribute.setValue() shouldn't cause any changes for
DigitalSubject. In other words setValue() for "in-memory" attribute should
invoke only "in-memory" changes for this attribute.

2. Attibute was returned by IDigitalSubject.getAttribute(). In this case it
is "stored" attribute and its value should be changed.

Thanks,
Sergey Lyakhov
----- Original Message -----
From: "Jim Sermersheim" <jimse@xxxxxxxxxx>
To: "'Higgins (Trust Framework) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
Sent: Wednesday, March 28, 2007 12:23 AM
Subject: [higgins-dev] Stored versus in-memory IProperty instances (was:IdAS
is now Java 1.4)


>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 3/27/07 10:51 AM >>>

<snip>

>I think we need to create a new "stored" instance of IProperty for each
>stored Digital Subject regardless of which type of IProperty ("stored" or
>"in-memory") was passed to setValue(). In this case there will be no any
>two or more Subjects which refers to the same "stored" instance of
>attribute, metadata or value.

I'm trying to envision what this would look like. Let's use some sample code
to talk about it:

IDigitalSubject mySubject1 = myContext.getSubject("subject1");
IDigitalSubject mySubject2 = myContext.getSubject("subject2");
IAttribute myAttribute = mySubject1.getAttribute("eyeColor", null);

// At this point, is myAttribute associated with MySubject1 in terms of
updates?
// In other words what happens here, does it only affect the in-memory copy,
or does it also affect mySubject1?
// I think you're opinion is that this should affect mySubject1.
myAttribute.setValue(buildSimpleValue("http://www.w3.org/2001/XMLSchema/normalizedString","blue"));


// Next, I assume all would agree that this would add the entire myAttribute
to mySubject2
Vector v = new Vector();
v.add(myAttribute);
String s = myContext.addSubject("http://...#person", "mySubject2", v, null);

// Here's where I'm confused.  Does this affect mySubject1, mySubjet2, both,
or neither?
myAttribute.setValue(buildSimpleValue("http://www.w3.org/2001/XMLSchema/normalizedString","brown"));

Jim

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top