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! Gustavo. 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] >
