Gustavo, You are proposing that your business object be partially loaded. This presents a problem because the collection represents all relations for a parent object (required for saving, updating, and deleting dependent objects). OJB has no way to know that a object is partially loaded, so a save will update all attributes and relations to the current state of the object. This could mean data loss or corruption.
The solution I think you are looking for is to create a layer on top of OJB that returns value objects (NOT business objects) and loads the child collections manually using whatever criteria you want. You will have to deal with how to merge these value objects back into the business layer if you allow changes on the value objects. Hope this gives you a start. Wally -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 8:47 AM To: OJB Users List Subject: Re: Need help to auto-retrieve some individuals Thanks Edson for your quick answer. We �ve already seen your approach. The problem we see with it,is in our real world, the fact that attributes values are more than two in some cases (male and female is just a set of two for this example), and as you say, in some cases there is a large numbre of childre. We envision our requirement (retrieving a subset of child objects) more as a behaviour pattern than a business method. Let�s say attribute is something like the object state, and values could be active, inactive, suspended, deprecated, preferred etc. and let say as you suggest, there is a very large number of children. There are so many combinations to hard code business methods for each persistent class. OJB capabilities to retrieve collections are great. I would like to see them enhaced to be able to retrieve collection sub sets just passing some "criteria". Arguments might be class collection name, attribute, value and connector (equal, not equal, less than etc.). In the mean time we are thinking about delegating this to a helper class or some storage controller thing in order to avoid coding class by class. We suspect this will not be that efficient in terms of database reads etc. compared to a pure OJB native solution. Thanks! . Edson Carlos Ericksson Richter <[EMAIL PROTECTED]> wrote on 27/04/2004 09:55:28 a.m.: > Unless your Father has a very large number of children (as can occur > in > a Construction and the elements of construction in a price building > system), you will find easier to get all childrens and implements two > business methods in your Father bean: getFemaleChildrens() and > getMaleChildrens(). > > So, you will have three ways to get the data you want, withou need to > execute more than two selects on database. If you use JavaBeans based > programming, when OJB call setChild, you can separate males and females, > and kee each in theyr own list... > > Just my 2c, > > Edson Richter > > > [EMAIL PROTECTED] wrote: > > >Hi all, > > > >Let's say we have an object name Father, who has a Child class collection > >(aggregate association). With the right repository settings (autoretrieve= > >true etc.) every time we "load" a father from the database, the children > >will be instantiated (they may be proxies or materialized). > > > >Here's our ignorance: when we retrieve a father we need the retrieved > >children collection, to be just a subset of the all father's children > >collection. The children are those with a any given attribute set to a any > >given value (let say just those children with gender attribute set to > >female). > > > >This is just like having a filter or criteria setting at the owned > >collection level. > >Please pay attention to the fact we do not want to filter the fathers > >based in some children attributes. We need retrieve all fathers, just > >filtering some children. > > > >We are aware we could retrieve the father an then iterate the collection > >discarding the children we do not need, but we need this to become a > >common feature for our classes, not just a business logic for a single > >app, therefore we would like to know how to handle this in general. > > > > > >Thanks in advance, > >Gustavo Faerman. > > > >Buenos Aires, Argentina > > > > > > > --------------------------------------------------------------------- > 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]
