sdo message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sdo] ISSUE 119: Projection and Keys
- From: "Barack, Ron" <ron.barack@sap.com>
- To: "Bryan Aupperle" <aupperle@us.ibm.com>, <sdo@lists.oasis-open.org>
- Date: Thu, 16 Oct 2008 01:49:20 +0200
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
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]