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: Bryan Aupperle <aupperle@us.ibm.com>
- To: sdo@lists.oasis-open.org
- Date: Thu, 16 Oct 2008 09:24:20 -0400
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]