Hi Bert, All that SDO requires is that every object being passed in a DataGraph is in the DataGraph's container. If the types themselves form a containment graph on their own, then that's the simplest case. If instead, the objects reference each other via non containment references, then it's the responsibility to the DAS to make sure that each object in the graph is ALSO the target of some containment reference. One way to do this is to simply use a special object as the root of the DataGraph that has direct containment references to the DataObjects of the graph and a maybe a non-containment reference to one of the contained DataObjects - the real root: This "dummy root object" simply acts as a container for the objects in the graph. This root object could be a generic type, or alternatively an instance of a dynamically created type for the specific user model. Take a look at the way the Tuscany RDB DAS creates dynamic root types like this.
Frank [EMAIL PROTECTED] wrote on 09/25/2006 06:03:55 AM: > Hi all, > > I've a question on the usage of SDO datagraphs and the role of > containment. > > [Background] > In our application suite, we have a large datamodel consisting of several > hundreds of domain classes. Client applications typically want to download > data of a subset of the model. However, the exact definition of this > subset (i.e. which domain classes and which relations) can vary quite a > lot depending on the application and also on configuration. We want to use > SDO to exchange data between client and server. > > [Problem] > To exchange data you need datagraphs. > Datagraphs require types that define a containment tree. [I have the > impression that this is in fact the definition of containment.] > Since clients can ask for very different subsets we need different > containment trees. > Containment is an integral part of a type, so we need also different > types. So, we need also different types. > One option is to use different namespaces for each subset. This helps a > bit. However, in our case we would have a huge amount of namespaces. Also > since configuration can change the subset we would also need a kind of > dynamic namespace that is not defined at development time. This is still > kind of feasible, but it is already getting complex. Then there is also > the issue that different namespace means different type, which is also not > that nice. > > [Alternative] > What we are thinking of is some kind of extension to SDO to allow the > specification of containment outside of the type definition. You can > imagine this as providing a set of properties each time a datagraph is > created. This set of properties would define the containment relation, > i.e. the tree of data that defines the datagraph. > > > Any ideas about this? > Is this still inline with the ideas of SDO? Has this kind of requirement > already been discussed somewhere? > > > Bert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
