Hi Kelvin, I think what Frank suggests is what we want. We will try the following. (1) define one type "Bag". This type has two properties. "rootObject" a single-valued property of type DataObject containing the root. The other, "element", is a contained multi-valued property also of type DataObject. (2) When transferring data always use the "Bag" type. One drawback is that the Bag doesn't contain the metadata anymore of its contents. So given a Bag you don't know what it is in it. But given that for us, the bag is immediately used by the one who asks for it, this might not be such a problem.
One reason why we don't want to define new types for each application, form or even request is that that would make life much too complex for us. For now, we are happy with subsets of our one model. And it is only that single model that we want to document and maintain. Most of the models we would make would differ only in details; defining dynamic types for all of these would make it even more complex than it is now. We already have a mapping to map our model onto the database so that mapping takes care of most of the database/legacy pecularities that we want to hide. So it's not such an issue to expose that model. Also, as we need a powerful query facility, we don't want to stray to far from the server-side model with yet another mapping. That would force us to implement a query facility as well; something which we want to avoid if possible. W.r.t. the dynamic types, we are already using that. Parts of our model are dynamic (as they depend for instance on region, customer, etc). These parts we model using dynamic types. thanks for the good replies! Bert "kelvin goodson" <[EMAIL PROTECTED]> 25/09/2006 15:26 Please respond to [email protected] To [email protected] cc Subject Re: dynamic containment in datagraphs Hi Bert, I was constructing a reply to your note, but Frank beat me to it ;-) So what I want to ask is, is it acceptable for you to always have the canonical model that you use in your persistence layer present in the data graphs that the application sees, or are you trying to implement some kind of data transfer object that abstracts away the shape of the persistence layer such that it is never visible to the application layer? (IIRC this is like a session facade in J2EE?). If it's acceptable for you to build views onto the canonical model using non-containment references then Frank's suggestion is fine. I was guessing that this was not the case. I'm sure you've been thinking quite deeply about this so I may just be having thoughts that you've already considered. If I understand your problem correctly, there are approaches to this which wouldn't need to be viewed as an extension to SDO. I think you want data transfer objects for which you a) declare types dynamically b) share those dynamic type definitions across layers c) define a mapping between your dynamic types and the canonical model used by your persistence layer a) can be done with, for example, XSDHelper.define() or TypeHelper.define(), b) the XSD or the graph of commonj.sdo.Type/Property instances passed to the methods above could be communicated between layers to make the type systems available to other layers c) Here's the bit where I guess there's be some work to do, and therefore potentially an area for extension, although my guess is it's best implemented on top of SDO. There's the mapping definition to be done and some logic would need to be implemented to act on the mapping. Before I spend too much time thinking about the various ways to slice and dice this let me just check with you that I'm reading between the lines correctly. Regards, Kelvin. On 25/09/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
