[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] ISSUE 119: Projection and Keys
Hi Frank,
I'd really like to get some more intelligent behavior on when projecting from keys to entities, but I'm not sure how to specify it. What I want to avoid is getting SDO into the business of managing SDOs, of having something like the JPA persistence manager, to maintain a map from keys to entities. We don't want to specify an SDO container, it's hard enough being a library.
The basic problem is that we don't know what the lifecycle and rules should be, though which any sort of map from keys to entities should be maintained. One reason why I thought it would be nice to bring the binder and projection together is that it would give us such lifecycle. A binder is essentially a context in which we could maintain the map from keys to entities. The lifetime of the map, and of the objects referenced in the map is the lifetime of the bindier, and the binder is a user object, that goes in and out of scope based on the user code.
I think the correct behavior when projecting from keys to entities is to require that for every distinct key in the input graph a single entity exists in the result graph. In terms of the lifetime of the map, this boils down to saying that the map must exist during the call to "project()" and is thrown away thereafter. My problem with this approach is that I always picture projection occuring lazilly. That is, we don't create (initially) a projected image of the entire graph, we project only the containment tree. Any non-containment relationships are projected only when they are used (ie, the user navigates the relationship). I think this is important for dealing with very large models. The approach to key-entity mapping seems to require that projection occur eagerly, that is, that the entire transitive closure is projected in a single call. This is maybe not so bad, the whole point of one of these "pruned" type systems is that the data graphs have a managable size. We can determine though analysis of the type definitions that we are projecting from a "key-context" to an "entity-context", from a pruned graph to a full graph. This implies a relationship between contexts, that some are fuller than others. I think this will be true in practice, but we haven't said anything like this in the spec, yet.
Ron
-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 8. August 2008 20:07
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] ISSUE 119: Projection and Keys
Hi Ron,
I'm pretty much on board with this proposal, but I wonder if we can
improve the default (no EntityManager) algorithm. Instead of always
creating a new Employee with only the key field set when projecting back
to context 1, I think we should be able to connect to existing Employee
with that key, if there is one.
I think the algorithm is straightforward, if we look at the graph being
projected with keys, as if there were no key properties. For example, when
projecting from C1 to C2, you pointed out that if we had no key
properties, we would have needed to pass the entire set of employees in
the graph because Employee has a reference to Department, which then has a
reference to all Employees. By projecting to a type with keys instead, we
avoided passing the rest of the graph, but we do still have a closure of
objects in C1 where key to Employee mappings can be found. I think it
would be reasonable to connect to any of those objects, if a key property
is set to a new value, when we project back from C2 to C1.
What do you think?
Frank.
"Barack, Ron" <ron.barack@sap.com>
08/03/2008 06:06 PM
To
<sdo@lists.oasis-open.org>
cc
Subject
[sdo] ISSUE 119: Projection and Keys
Use Cases for Keys and Projection
We begin with a motivating use case.
Domain models tend to be larger and complex than the views used by
individual clients. Moreover, when going from a large server-side model,
it is necessary to define the scope of the data which should be
transmitted to a remote client. The boundaries of the data which should be
transmitted in a single packet must somehow be defined. On the other hand,
the door must be left open for clients to further explore the model in
succeeding calls to the server.
Imagine a service that returns an Employee object. In the domain model,
Employee has a refence to Department, and Department in turn has a list of
all Employees. If we define the transmission packet to be the transient
closure reachable from Employee, then we can never send a single employee,
we will always send the complete list of employees in the department.
Our approach is to use keys to represent the boundary points in a
transmission packet. It is assumed that clients that wish to explore the
model beyond these boundaries will be able to use the keys to somehow
perform lookups, but the API through which this is done is out-of-scope
for SDO (being more of a DAS issue).
As an example, we can imagine that the server has a SDO type system in
which Employee has a property with type Department. In the client's type
system, however, the corresponding property has type {commonj.sdo}string.
This value would represent the identity of the Department. The basic
functionality we wish to achive is to allow projection between these two
HelperContexts.
Keys and Projection
A type and its keyType are compatible with each other. That mean, an
object with a reference to an entity in one context can be projected onto
an object with a reference to the key type in another context.
We illustrate this with an example.
HelperContext #1
Type Employee
* property - id (Integer) - KEY
* property - name (String)
* property - direct-report (List of Employee)
is compatible with the metamodel
HelperContext #2
Type Employee
* property - id (Integer) - KEY
* property - name (String)
* property - direct-report (List of Integer)
Here we see the type of the direct-report property has been replaced in
the second HelperContext with the corresponding key type.
The projection from an entity to its key has some important semantic
differences when compared with projection between entities. Projection
between entities creates a new view of the same underlying data. By
contrast, a key does not represent a view, but rather a reference to an
entity in the underlying data model. When working with different views of
the same underlying data, it is natural that changes in one view are
reflected in all other views. By contrast, changing the value of a key
changes the target of the reference rather than the value of the key
property in the referenced data object. 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.
We illustrate with an example. Note that the example uses containment
relationships in both contexts. This is done for clarity, since it allows
an XML representation of the data. The use-case, however, is stronger
when the contexts have different (or perhaps no) containment structures.
Imagine the following data in HelperContext #1
<employee id="11">
<name>Foo Bar</name>
<direct-report id="21">
<name>Jane Doe</name>
</direct-report>
<direct-report id="31">
<name>Jim Jones</name>
</direct-report>
<direct-report id="22">
<name>John Smith</name>
</direct-report>
</employee>
After projecting to HelperContext #2, we have the following data
<employee id="11">
<name>Foo Bar</name
<direct-report>21</direct-report>
<direct-report>31</direct-report>
<direct-report>22</direct-report>
</employee>
If we imagine the client changes the list of direct reports, so that the
second item in the list has value ?41? instead of ?31?, then the meaning
of the change is not that the employee with name ?Jim Jones? now has a new
ID, but that ?Jim Jones? has been replaced by another employee.
On projecting from context 2 back into context 1, the instance of Employee
with id="22" would be detached from the Employee with id="11" (tracked as
a delete in the ChangeSummary if applicable). Also a new Employee with
id="41" would be created and added as a direct report to the Employee with
id="11" (tracked as a create in the ChangeSummary if applicable). The
created entity has default values for all properties other than the key
fields. Projecting this data from context 2:
<employee id="11">
<name>Foo Bar</name
<direct-report>21</direct-report>
<direct-report>41</direct-report>
<direct-report>22</direct-report>
</employee>
Into context 1 yields:
<employee id="11">
<name>Foo Bar</name>
<direct-report id="21">
<name>Jane Doe</name>
</direct-report>
<direct-report id="41"/>
<direct-report id="22">
<name>John Smith</name>
</direct-report>
</employee>
Before the specification goes final, I think we want to add a further API
so that users can specify additional logic so that, using the key, the
appropriate entity can by found, eg, using an EntityManager. The API used
to add the resolver will be dependent on the resolution to ISSUE 134.
Therefore, for the CD, I believe we should specify this default behavior,
leaving the door open to adding a further API. If anyone is interested in
the API that has previously proposed, you may find it detailed here:
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200806/msg00033.html
Best Regards,
Ron
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]