You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Brendan Miller <bm...@dotster.com> on 2008/01/10 19:30:45 UTC
determine if new criteria is called for
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
Re: determine if new criteria is called for
Posted by Brendan Miller <bm...@dotster.com>.
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" <bm...@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
Re: determine if new criteria is called for
Posted by Thomas Fischer <fi...@seitenbau.net>.
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
"Brendan Miller" <bm...@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
Re: determine if new criteria is called for
Posted by Brendan Miller <bm...@dotster.com>.
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