db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brendan Miller" <bmil...@dotster.com>
Subject Re: determine if new criteria is called for
Date Tue, 15 Jan 2008 19:20:56 GMT
On Tue, Jan 15, 2008 at 08:04:36PM +0100, Thomas Fischer wrote:
> Though I have not tested the behaviour, this seems to be a bug, so an entry
> into jira would be appreciated.
> 
> However, I have never used the getSomeClass(Criteria) myself, I've always
> used the getSomeClass() variant without the connection. The reason is that
> in my eyes, one does not want to cache arbitrary collections, but only the
> complete sets. Whenever I wanted to have subsets of relationship
> collections, I have used the Peer.doSelect(criteria) and have thrown away
> the result after using it.
> 
> You might want to turn the caching off and set torque.objectIsCaching to
> false, this would solve your problem at the cost of not having any cache of
> foreign key relationships.

Thomas:

Good stuff to consider.  I will enter a jira shortly after I am sure I
know what to enter to be precise enough.

Most times I use Peer.doSelect(criteria), but when it's related objects
I'm after, the getRelatedObjects() seemed so handy.  Since there's a
getRelatedObjects(criteria) method, I fell into the "customizing the
criteria" trap!  If one really wanted the ultimate caching mechanism,
one could cache a hash of Critria->Collection<SomeClass>, but that 
would probably be overkill.

Brendan

> 
> "Brendan Miller" <bmiller@dotster.com> schrieb am 15.01.2008 18:32:26:
> 
> > Can some kind soul shed some light on my predicament?  Thanks,
> > Brendan
> >
> > On Thu, Jan 10, 2008 at 10:30:45AM -0800, Brendan Miller wrote:
> > >
> > > I know we're in the middle of an RC release, but there is something
> that
> > > continues to bother me.
> > >
> > > The generator for object classes creates
> > >
> > >     public List<SomeClass> getSomeClasss(Criteria criteria) throws
> TorqueException
> > >
> > > methods for each class that has a foreign key to this object's table.
> > > In these methods, we have the following
> > >
> > >         // the following code is to determine if a new query is
> > >         // called for.  If the criteria is the same as the last
> > >         // one, just return the collection.
> > >                     criteria.add(SomeClassPeer.MYCLASS_ID, getID());
> > >                     if (!lastSomeClassCriteria.equals(criteria))
> > >         {
> > >             collSomeClasss = SomeClassPeer.doSelect(criteria);
> > >         }
> > >
> > > If my application does something like
> > >
> > >     List<SomeClass> allSomeClasses = getSomeClasss();
> > >
> > >     // ...
> > >
> > >     Criteria crit = new Criteria();
> > >     crit.add(SomeClassPeer.TYPE, "foo");
> > >     List<SoemClass> fooSomeClasses = getSomeClasss(crit);
> > >
> > > the last line will throw a NullPointerException because
> > >
> > > a) collSomeClasss is not null
> > > b) the object is not new
> > > c) lastSomeClassCriteria is null
> > >
> > > I have lots of occasion to find the releated SomeClass objects where
> > > other criteria is in place, say an AMOUNT > 4.00 or a TYPE == "special"
> > > or somesuch.  I cannot use this method passing my own Criteria when the
> > > whole list of related objects has already been retrieved (the
> collection
> > > is no longer null), because the lastSomeClassCriteria is still null.
> > >
> > > Does this make sense?  Please don't tell me that I'm "misusing Torque"
> > > :)  This seems so obvious.  But then...
> > >
> > > Could it be fixed with a simple patch to the templates to replace
> > >
> > >     if (!last<RelatedTableClass>Criteria.equals(criteria))
> > >
> > > with
> > >
> > >     if (!criteria.equals(last<RelatedTableClass>Criteria))
> > >
> > > or
> > >
> > >     if (last<RelatedTableClass>Criteria == null ||
> > >         !last<RelatedTableClass>Criteria.equals(criteria))
> > >
> > > ??
> > >
> > > Thanks,
> > >
> > > Brendan Miller
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> > > For additional commands, e-mail: torque-dev-help@db.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-dev-help@db.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message