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
>
This archive was generated by hypermail 2.0.0 : Thu Jul 08 2004 - 12:09:25 EDT