I think you are right. I think there are two ways of looking at this. 1. From an OO programing point of view, OJB could be seen solely as a persistance mechanism for objects. Queries should be used for realising a collection of objects or a single object. The single object (or each of the collection of objects) should be complete trees (ie they should come back from OJB as they went in).
2. From a Modeling point of view, OJB could be seen not only as a tool for storing objects in a persistant manner, but also as a tool for working with those objects. One of the fundamental methods for working with data is projection: specifying a tree to match, and finding matching occurances of that tree. This operation of projection is provided by SQL, but not in the same manner, as all matching subtrees are returned (ie Managers are repeated on each row of the results for their employees). OJB put's it back together. The kind of projection we are debating is provided with Conceptual Graphs (peirce logic), and it works well. However wether it should be applied to OJB depends on which view you take (1 and 2 above). Well, that's my thoughts! Feel free to disregard or discuss as you so feel inclined! Daniel. ----- Original Message ----- From: "Guido Beutler" <[EMAIL PROTECTED]> > Exactly and this is one reason why delegating the work to OJB for > queries. This * must* not be bad design at all. > It depends on the application I think. > Another point is that I have a aditional hand written subselect which > must be maintained and I can not see > this problem by looking at the deployment descriptor. By using a > queryCustomizer you can see at the > descriptor that there is a dependency and where to make modifications if > neccessary. > > best regards, > > Guido --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
