OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sdo] ISSUE 119: Projection and Keys


Hello everyone,

This is my initial feedback, I wanted to make sure I send something
before Friday.

I think several things need to be changed in the original proposal's
wording:

- the beginning chapter "Use Cases for Keys and Projection", if it is
supposed to be part of the proposal needs to be changed. I certainly
would not agree with the "Domain models tend to be larger and more
complex than the views used by individual clients" statement being
presented as motivation for this feature. If it was intended just to
kick start the discussion and not to be part of the spec, then it is
fine.

- In the call on Tuesday I think we have said that the "roundtrip"
projection case is not the sweet spot for this feature, yet the old
proposal spends a significant amount of time explaining how this case
works. Of course, we may have to revisit SDO-66 as well once we get more
insight into how things work.

Thanks,
Radu

On Thu, 2008-10-16 at 06:24 -0700, Bryan Aupperle wrote:
> 
> The reason I used "non-containment" is that references to a contained
> object can be serialized and deserialized,  so it is not strictly
> necessary to project them to keys.  I suppose the treatment of
> references to contained objects would be controlled by the type in the
> projected context. 
> 
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> 
> Research Triangle Park,  NC 
> +1 919-254-7508 (T/L 444-7508)
> Internet Address: aupperle@us.ibm.com 
> 
> 
> "Barack, Ron" <ron.barack@sap.com> 
> 
> 10/15/2008 07:49 PM 
> 
> 
>                To
> Bryan
> Aupperle/Raleigh/IBM@IBMUS, <sdo@lists.oasis-open.org> 
>                cc
> 
>           Subject
> RE: [sdo] ISSUE
> 119:  Projection
> and Keys
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Bryan, 
>   
> Although I think it's certainly the typical case, I don't know why we
> have to restrict the entity->key projection to be only
> non-containment, as you seem to imply.  I think the statements all
> hold even if you removed "non-containment".  Other than that, thanks
> for this concise summary of the proposal. 
>   
>   
>   
> Ron 
>   
> 
> 
> ______________________________________________________________________
> From: Bryan Aupperle [mailto:aupperle@us.ibm.com] 
> Sent: Mittwoch, 15. Oktober 2008 21:06
> To: sdo@lists.oasis-open.org
> Subject: Re: [sdo] ISSUE 119: Projection and Keys
> 
> 
> So as I understand it - 
> 
> Projection without keys: 
> - This represents a new view on the same data in memory (similar to a
> union in C) 
> - The original object may or may not be live, but if it is, then any
> changes made in the projected object would  be observable in the
> original object. 
> - O1 == project(project(O1, C2), C1) 
> 
> Projections with keys: 
> - Projection of non-containment references has key values instead of
> the non-containment references 
> - Changing non-key properties in the projected object behaves as above
> - Changing key properties in the projected object is equivalent to
> changing the non-containment references in the original object
> - When projecting from key values to non-containment references, all
> identical key values in a graph are projected to references to the
> same (new) object
> - If O1 references O11 then project(project(O1, C2), C1) = O3 which
> references O31 where O31 has the same key value as O11 and all non-key
> property values of O3  == the corresponding property values of O1
> 
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> 
> Research Triangle Park,  NC 
> +1 919-254-7508 (T/L 444-7508)
> Internet Address: aupperle@us.ibm.com 
> 
> "Barack, Ron" <ron.barack@sap.com> 
> 
> 10/15/2008 12:00 PM 
> 
> 
> 
>                To
> <sdo@lists.oasis-open.org> 
>                cc
> 
>           Subject
> [sdo] ISSUE 119:
>  Projection and
> Keys
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Everyone, 
> 
> Here is a link to the email that contains my last proposal:
>  http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200808/msg00060.html 
> 
> I'll repeat the section relevant to identity when projecting from keys
> to entities: 
> 
> Conversely, when projecting from a key to an entity then for each
> distinct key value within the graph being projected, all references to
> that key must resolve to the same entity. 
> 
> In many scenarios data will round-trip between contexts, including
> between contexts in which entity map to keys. Let us consider two
> context Ce and Ck, representing the entity and the key context,
> respectively, and a DataObject Oe, in context Ce. Projecting Oe into
> Ck returns a DataObject, Ok. The transitive closure reachable from Ok
> is Gk. Every key value in Gk maps to an single entity in Ce, and it is
> this entity is that is found when Ok (and effective, all of Gk) is
> projected back into Ce. In cases where the user has set a key property
> to a value that is not found in Gk, then, as a result of projecting Ok
> into Ce, a new entity will be created. The created entity has default
> values for all properties other than the key fields. 
> 
> Ron 
> 
> 
> 
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]