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: 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.


-----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?


"Barack, Ron" <ron.barack@sap.com> 
08/03/2008 06:06 PM


[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 
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 id="31">
                <name>Jim Jones</name>
        <direct-report id="22">
                <name>John Smith</name>
After projecting to HelperContext #2, we have the following data 
<employee id="11">
        <name>Foo Bar</name
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
Into context 1 yields: 
<employee id="11">
        <name>Foo Bar</name>
        <direct-report id="21">
                <name>Jane Doe</name>
        <direct-report id="41"/>
        <direct-report id="22">
                <name>John Smith</name>
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: 

Best Regards, 

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:

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