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


Title: ISSUE 119: Projection and Keys
Hi
 
Of course projection works with compound keys, but they do require some special handling, which I've described in my proposal, specifically when I say

When projecting from an entity to a key, a new instance of the key is always created. By contrast, when we project from entity to entity, we get the same number of objects in the target HelperContext that we had in the source HelperContext.

It could be that we may even want to add a restriction that the key data object (compound keys are data objects) MUST be contained (as opposed to referenced) by the object that uses them...I was hoping to note bring containment into the picture, but certainly for conversion to XML-based contexts this is almost always the case.
 
For your second question, we've said in 66 that they types may only differ in prescribed ways, and key definitions wasn't one of them, so officially projecting from C1 to C2 is not portable.  It would work in our implementation tho.  Why not? when casting from C1 to C2 keys really aren't even involved.  The only difference would be in how non-containment reference are serialized to XML.  At least for us, projection should still work. 
 
The question you ask in part b is also covered in SDO 66, rather than this proposal.  This projection is legal, containment MUST be ignored when considering if projection is allowed between two types.
 
I think the question you wanted to ask is to suppose in C0 company has a string property named "employee".  Assuming employee.id and employee.name are also both string properties, then you could project from either C1 or C2 to C0.  Projecting from C1 to C0 and then to C2 would generate employee objects with id strings for names, but I consider this a user error.   Semantically, C0 must decide whether to use names or ids as values, and the model has no way of detecting this semantic difference.
 
Ron "I'm staying up to watch the debate" Barack
 


From: Cezar Andrei [mailto:cezar.andrei@oracle.com]
Sent: Mittwoch, 15. Oktober 2008 21:19
To: Barack, Ron; sdo@lists.oasis-open.org
Subject: RE: [sdo] ISSUE 119: Projection and Keys

Two questions for the proposal:

 

  1. If I remember correctly, we agreed earlier this year that composite keys can be defined. How will it work it this case, if at all?
  2. Also, if there are two contexts C1 and C2, and a type Employee with id and name properties, in C1 id is key and in C2 name is key.
    1. Would project work from e1 in C1 to an e2 in C2?
    2. If yes, than projection of their containment objects should work also? Let’s say, in context C0, type Company has a containment property employees, and C1 and C2 the employees property is non-containment. Will object company0 in C0 will be able to be projected in C1 and C2?

 

Cezar

 


From: Barack, Ron [mailto:ron.barack@sap.com]
Sent: Wednesday, October 15, 2008 11:01 AM
To: sdo@lists.oasis-open.org
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]