Support for dynamic containment
-------------------------------
Key: TUSCANY-1918
URL: https://issues.apache.org/jira/browse/TUSCANY-1918
Project: Tuscany
Issue Type: New Feature
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: bert.robben
In SDO, the boundaries of a datagraph are defined by the containment relation.
Only objects which can be reached from the root object by following properties
that are contained are part of the datagraph. Containment is defined at the
type level.
In cases where applications need to dynamically select what information they
want, this fixed containment relationship is an issue. For instance, suppose in
a medical context you have defined a number of types defines to represent
patients together with their clinical (e.g. procedures they have taken) and
administrative data (for instance their address). The type definition needs to
decide on the containment of the clinical and administrative data. However it
is hard to decide whether or not the administrative and clinical data should be
contained because some applications might only need clinical or administrative
data and others might need both. In cases where the type system is large or
where there are large volumes of data involved (for instance in the example,
procedures could have an associated pdf-report property) this becomes a real
issue.
Current solutions within the SDO framework could be (for the interested, there
has been a mail thread about this a while ago in the user mailing list)
- Each app shoud define its own type with an appropriate containment relation.
The downside of this is a proliferation of types.
- The main types should not have any containment relations. Containment is
specified using a synthetic type. Think of this as a special list type that
contains its elements. The root of the datagraph then would be an instance of
such a list type. All instances that are needed should be put in this flat list.
I would like to propose an alternative solution. In this solution, containment
would not be specified at the type level. Whenever the boundary of a datagraph
is needed (for instance when an xml document it be generated or a datagraph is
to be exchanged between for instance a client and a server), the application
should provide appropriate information that specifies exactly what is part of
the graph and what not. This can be seen as a select clause for sql, or even
better as a set of fetch joins in Hibernate. This would give the application
control over exactly what it wants. In the example for instance, the
application can easily decide at each point whether or not it would want the
address information together with the patient data.
This proposal would have a number of interesting implications.
- What is the implication of this for cases where datagraphs are represented as
xml documents that should be according to an xml schema?
- How to deal with links to objects that don't belong to the datagraph? One
strategy could be just to drop them. Another one to provide some kind of proxy.
Interested parties can have a look at our SDO implementation (see also JIRA
1527 and 1493) where we try to support this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
