Joe and Andrus,
Thanks for your suggestions. The case I had in mind would require me to
go in from the root since I need the Key of the root as part of my
Expression so what I have in mind is probably creating a
getStuff(Expression e). If Expression e is null, I call the regular
getStuff() otherwise I do as described below.
Thanks again, Joris.
Andrus Adamchik wrote:
> I see... I agree - sometimes changing the design may be a better option.
>
> Another comment on the solution that I suggested. It looks attractive
> in case you still want to go from the root of the hierarchy. However I
> just noticed that there is a caveat - a query name must be unique for
> each object... So whenever you create a named query to fetch data,
> build a name based on the ObjectId. E.g.:
>
> public List getStuff() {
> Expression e = ...
> SelectQuery q = new SelectQuery(MyObject.class, e);
>
> // make sure the name is unique for each object...
> q.setName(getObjectId().toString());
>
> q.setCachePolicy(GenericSelectQuery.LOCAL_CACHE);
> q.setRefreshingObjects(false);
>
> return getDataContext().performQuery(query);
> }
>
>
> On Jul 8, 2004, at 11:46 AM, McDaniel, Joe R. wrote:
>
>> Nope! What I thought I was saying was to use an object down the
>> hierarchy (what would be retrieved by getStuff) as the base object
>> since, in general, you can add conditions for objects "above" but not
>> "below" the base object.
>>
>> In my case I had Plates with Wells containing Primers for Genes and I
>> wanted Gene.information for all Plates in a set. If I started with
>> Plates, then I had problems having to do individual queries on objects
>> below (especially since Wells can contain many things other than Primers
>> pointing to Genes). By starting with Wells, I could navigate more easily
>> and attach conditions and the query looked much closer to what I would
>> have done with a standard JDBC call. I also used the preload calls to
>> cut down on the individual calls to populate some of the children.
>>
>> Best,
>>
>> Joe
>>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andru..bjectstyle.org]
>> Sent: Thursday, July 08, 2004 10:36 AM
>> To: cayenne-use..bjectstyle.org
>> Subject: Re: Filter a to-many relationship
>>
>>
>> A solution suggested by Joe (if I understand it correctly) is to
>> override getStuff() to perform a custom query instead of relying on
>> automatic relationship resolution.
>>
>> This will work, however keep in mind that unlike regular relationship,
>> such implementation will not cache the results, so each invocation will
>> make a trip to the DB. A way to improve it is to use "local cache"
>> setting on such query. Result caching was introduced just recently
>> (http://objectstyle.org/cayenne/userguide/fetch/result-caching.html)
>> and seems to be ideal in your situation (hmm... that's the first time
>> I've thought of such use of caching... should add it to the FAQ I
>> guess).
>>
>> Cheers
>> Andrus
>>
>
>
-- Joris Melchior jmelchi..ogers.com--------------------------------- GnuPG Public Key http://members.rogers.com/jmelchio/publickeyjoris.txt GnuPG Key fingerprint = 3983 3906 A594 DE1E 0D7A 0A22 22CC 1098 2D82 44A9
This archive was generated by hypermail 2.0.0 : Thu Jul 08 2004 - 18:54:10 EDT