You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2008/05/03 17:57:31 UTC
Fwd: Query.setRefreshingObjects(boolean)
Figured I'd resend the message to this list to get more feedback. Do
many people find this API useful?
My main motivation for removal of this API is to reduce confusion. It
overlaps with query caching and the subtle difference between
"setRefreshingObjects" and "setCachePolicy" is unclear to many users.
At the same time the later does not *directly* replace the former, and
I can see how under some very special circumstances
"setRefreshingObjects(false)" could yield marginally better
performance (e.g. a set of queries with a large # of combinations of
parameters, but all searching the same underlying data set that rarely
changes), but IMO that does not justify the confusion it leaves...
So I guess a more specific question is - does anyone's application
heavily rely on this optimization and will suffer if we get rid of it
in the sake of better clarity?
Andrus
Begin forwarded message:
> From: Andrus Adamchik <an...@objectstyle.org>
> Date: April 18, 2008 12:02:27 AM GMT+03:00
> To: dev@cayenne.apache.org
> Subject: Query.setRefreshingObjects(boolean)
> Reply-To: dev@cayenne.apache.org
>
> Anyone's using "SomeQuery.setRefreshingObjects(false)"?
>
> I haven't been using this since WebObjects days, and with all the
> Cayenne query cache/refresh options, don't find a need for it at
> all. Any objections to deprecating this parameter and actually
> ignoring it in runtime?
>
> (BTW, this was brought up before, but never acted upon:)
>
> http://objectstyle.org/cayenne/lists/cayenne-devel/2006/02/0073.html
>
> Andrus
>
Re: Query.setRefreshingObjects(boolean)
Posted by Michael Gentry <bl...@gmail.com>.
All of my exceptions are at runtime. :-)
On Mon, May 5, 2008 at 6:21 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> You don't have to declare the throw clause if it's a RuntimeException.
> The method signature doesn't have to change.
RE: Query.setRefreshingObjects(boolean)
Posted by Scott Anderson <sa...@airvana.com>.
Of course, how could I forget!
Regardless, what's the point of providing API that compiles and then
ambiguously breaks?
-----Original Message-----
From: Mike Kienenberger [mailto:mkienenb@gmail.com]
Sent: Monday, May 05, 2008 6:21 PM
To: user@cayenne.apache.org
Subject: Re: Query.setRefreshingObjects(boolean)
You don't have to declare the throw clause if it's a RuntimeException.
The method signature doesn't have to change.
On 5/5/08, Scott Anderson <sa...@airvana.com> wrote:
> > I don't see
> > much benefit to providing a binary-compatible method API that does
> > nothing.
>
> ...
>
> > Another possibility is to @deprecate the method and have it
> > unconditionally throw a RuntimeException telling the developer to
> > rewrite using query cache options.
>
>
> Adding a Throws clause to the method would change its signature,
thereby
> breaking the binary compatibility of the method. It's a good idea,
but
> it won't solve that problem. :)
>
> Regards,
>
> Scott
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> Sent: Monday, May 05, 2008 5:01 PM
> To: user@cayenne.apache.org
> Subject: Re: Query.setRefreshingObjects(boolean)
>
> Just to reiterate, I see no problem with axing it entirely. I don't
> think we have to nicely deprecate everything since we're now in 3.0
> and it's marked unstable.
>
> However, we should make the need for change obvious. I don't see
> much benefit to providing a binary-compatible method API that does
> nothing. As an end-user, I want to see things either work as they
> always worked, or be given a clear unavoidable indication that work
is
> required on my part to fix it.
>
> Another possibility is to @deprecate the method and have it
> unconditionally throw a RuntimeException telling the developer to
> rewrite using query cache options.
>
> On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> > Actually I was going to do the opposite, but since we've set the
> backwards
> > compatibility bar for ourselves pretty high in the past, I guess I
am
> > persuaded to go with deprecated-but-don't-cripple approach. I guess
> that
> > means also putting a deprecation note in the Modeler next to
refresh
> > checkbox.
> >
> > Andrus
> >
> >
> > On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
> >
> >
> > > I'd like to second the opinion that deprecated still works (until
> > > removed), but is discouraged from use. I believe that is what
> Andrus
> > > intends, though, given previous API changes.
> > >
> > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger
> <mk...@gmail.com>
> > wrote:
> > >
> > > > I guess my problem is that to me @deprecate means "it still
works
> like
> > > > it used to, but it won't work in a future version and it's time
> for
> > > > you to change your code", but that's not what's going to happen
> here.
> > > >
> > > > That's why if we're not really @deprecating it but crippling
it,
> then
> > > > I'd recommend removing it. Giving end-users the false-hope
that
> > > > things are working as usual isn't very nice.
> > > >
> > > > You know the details of this particular situation better than I
> do,
> > > > though. If you don't think silently doing nothing will affect
> > > > expected program behavior, go for it.
> > > >
> > > >
> > > >
> > > > On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> > > > >
> > > > >
> > > > >
> > > > > > To me, that sounded like you were going to change the
behavior
> > rather
> > > > > > than just mark the method as @deprecated.
> > > > > >
> > > > > >
> > > > >
> > > > > I was planning to do both. Although we may decide to be
gentle
> about
> > it and
> > > > > deprecate the method, but preserve the functionality (which
will
> put a
> > bit
> > > > > of extra maintenance burden on us).
> > > > >
> > > > > I am leaning towards the first option (deprecate and stop
> invoking),
> > > > > especially since the nature of the change results in enhanced
> data
> > > > > consistency, so there won't be any unpleasant surprises.
> > > > >
> > > > > Andrus
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: Query.setRefreshingObjects(boolean)
Posted by Mike Kienenberger <mk...@gmail.com>.
You don't have to declare the throw clause if it's a RuntimeException.
The method signature doesn't have to change.
On 5/5/08, Scott Anderson <sa...@airvana.com> wrote:
> > I don't see
> > much benefit to providing a binary-compatible method API that does
> > nothing.
>
> ...
>
> > Another possibility is to @deprecate the method and have it
> > unconditionally throw a RuntimeException telling the developer to
> > rewrite using query cache options.
>
>
> Adding a Throws clause to the method would change its signature, thereby
> breaking the binary compatibility of the method. It's a good idea, but
> it won't solve that problem. :)
>
> Regards,
>
> Scott
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienenb@gmail.com]
> Sent: Monday, May 05, 2008 5:01 PM
> To: user@cayenne.apache.org
> Subject: Re: Query.setRefreshingObjects(boolean)
>
> Just to reiterate, I see no problem with axing it entirely. I don't
> think we have to nicely deprecate everything since we're now in 3.0
> and it's marked unstable.
>
> However, we should make the need for change obvious. I don't see
> much benefit to providing a binary-compatible method API that does
> nothing. As an end-user, I want to see things either work as they
> always worked, or be given a clear unavoidable indication that work is
> required on my part to fix it.
>
> Another possibility is to @deprecate the method and have it
> unconditionally throw a RuntimeException telling the developer to
> rewrite using query cache options.
>
> On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> > Actually I was going to do the opposite, but since we've set the
> backwards
> > compatibility bar for ourselves pretty high in the past, I guess I am
> > persuaded to go with deprecated-but-don't-cripple approach. I guess
> that
> > means also putting a deprecation note in the Modeler next to refresh
> > checkbox.
> >
> > Andrus
> >
> >
> > On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
> >
> >
> > > I'd like to second the opinion that deprecated still works (until
> > > removed), but is discouraged from use. I believe that is what
> Andrus
> > > intends, though, given previous API changes.
> > >
> > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger
> <mk...@gmail.com>
> > wrote:
> > >
> > > > I guess my problem is that to me @deprecate means "it still works
> like
> > > > it used to, but it won't work in a future version and it's time
> for
> > > > you to change your code", but that's not what's going to happen
> here.
> > > >
> > > > That's why if we're not really @deprecating it but crippling it,
> then
> > > > I'd recommend removing it. Giving end-users the false-hope that
> > > > things are working as usual isn't very nice.
> > > >
> > > > You know the details of this particular situation better than I
> do,
> > > > though. If you don't think silently doing nothing will affect
> > > > expected program behavior, go for it.
> > > >
> > > >
> > > >
> > > > On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> > > > >
> > > > >
> > > > >
> > > > > > To me, that sounded like you were going to change the behavior
> > rather
> > > > > > than just mark the method as @deprecated.
> > > > > >
> > > > > >
> > > > >
> > > > > I was planning to do both. Although we may decide to be gentle
> about
> > it and
> > > > > deprecate the method, but preserve the functionality (which will
> put a
> > bit
> > > > > of extra maintenance burden on us).
> > > > >
> > > > > I am leaning towards the first option (deprecate and stop
> invoking),
> > > > > especially since the nature of the change results in enhanced
> data
> > > > > consistency, so there won't be any unpleasant surprises.
> > > > >
> > > > > Andrus
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
RE: Query.setRefreshingObjects(boolean)
Posted by Scott Anderson <sa...@airvana.com>.
> I don't see
> much benefit to providing a binary-compatible method API that does
> nothing.
...
> Another possibility is to @deprecate the method and have it
> unconditionally throw a RuntimeException telling the developer to
> rewrite using query cache options.
Adding a Throws clause to the method would change its signature, thereby
breaking the binary compatibility of the method. It's a good idea, but
it won't solve that problem. :)
Regards,
Scott
-----Original Message-----
From: Mike Kienenberger [mailto:mkienenb@gmail.com]
Sent: Monday, May 05, 2008 5:01 PM
To: user@cayenne.apache.org
Subject: Re: Query.setRefreshingObjects(boolean)
Just to reiterate, I see no problem with axing it entirely. I don't
think we have to nicely deprecate everything since we're now in 3.0
and it's marked unstable.
However, we should make the need for change obvious. I don't see
much benefit to providing a binary-compatible method API that does
nothing. As an end-user, I want to see things either work as they
always worked, or be given a clear unavoidable indication that work is
required on my part to fix it.
Another possibility is to @deprecate the method and have it
unconditionally throw a RuntimeException telling the developer to
rewrite using query cache options.
On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> Actually I was going to do the opposite, but since we've set the
backwards
> compatibility bar for ourselves pretty high in the past, I guess I am
> persuaded to go with deprecated-but-don't-cripple approach. I guess
that
> means also putting a deprecation note in the Modeler next to refresh
> checkbox.
>
> Andrus
>
>
> On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
>
>
> > I'd like to second the opinion that deprecated still works (until
> > removed), but is discouraged from use. I believe that is what
Andrus
> > intends, though, given previous API changes.
> >
> > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger
<mk...@gmail.com>
> wrote:
> >
> > > I guess my problem is that to me @deprecate means "it still works
like
> > > it used to, but it won't work in a future version and it's time
for
> > > you to change your code", but that's not what's going to happen
here.
> > >
> > > That's why if we're not really @deprecating it but crippling it,
then
> > > I'd recommend removing it. Giving end-users the false-hope that
> > > things are working as usual isn't very nice.
> > >
> > > You know the details of this particular situation better than I
do,
> > > though. If you don't think silently doing nothing will affect
> > > expected program behavior, go for it.
> > >
> > >
> > >
> > > On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> > >
> > > >
> > > >
> > >
> > >
> > >
> > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> > > >
> > > >
> > > >
> > > > > To me, that sounded like you were going to change the behavior
> rather
> > > > > than just mark the method as @deprecated.
> > > > >
> > > > >
> > > >
> > > > I was planning to do both. Although we may decide to be gentle
about
> it and
> > > > deprecate the method, but preserve the functionality (which will
put a
> bit
> > > > of extra maintenance burden on us).
> > > >
> > > > I am leaning towards the first option (deprecate and stop
invoking),
> > > > especially since the nature of the change results in enhanced
data
> > > > consistency, so there won't be any unpleasant surprises.
> > > >
> > > > Andrus
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Query.setRefreshingObjects(boolean)
Posted by Mike Kienenberger <mk...@gmail.com>.
Just to reiterate, I see no problem with axing it entirely. I don't
think we have to nicely deprecate everything since we're now in 3.0
and it's marked unstable.
However, we should make the need for change obvious. I don't see
much benefit to providing a binary-compatible method API that does
nothing. As an end-user, I want to see things either work as they
always worked, or be given a clear unavoidable indication that work is
required on my part to fix it.
Another possibility is to @deprecate the method and have it
unconditionally throw a RuntimeException telling the developer to
rewrite using query cache options.
On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> Actually I was going to do the opposite, but since we've set the backwards
> compatibility bar for ourselves pretty high in the past, I guess I am
> persuaded to go with deprecated-but-don't-cripple approach. I guess that
> means also putting a deprecation note in the Modeler next to refresh
> checkbox.
>
> Andrus
>
>
> On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
>
>
> > I'd like to second the opinion that deprecated still works (until
> > removed), but is discouraged from use. I believe that is what Andrus
> > intends, though, given previous API changes.
> >
> > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <mk...@gmail.com>
> wrote:
> >
> > > I guess my problem is that to me @deprecate means "it still works like
> > > it used to, but it won't work in a future version and it's time for
> > > you to change your code", but that's not what's going to happen here.
> > >
> > > That's why if we're not really @deprecating it but crippling it, then
> > > I'd recommend removing it. Giving end-users the false-hope that
> > > things are working as usual isn't very nice.
> > >
> > > You know the details of this particular situation better than I do,
> > > though. If you don't think silently doing nothing will affect
> > > expected program behavior, go for it.
> > >
> > >
> > >
> > > On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> > >
> > > >
> > > >
> > >
> > >
> > >
> > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> > > >
> > > >
> > > >
> > > > > To me, that sounded like you were going to change the behavior
> rather
> > > > > than just mark the method as @deprecated.
> > > > >
> > > > >
> > > >
> > > > I was planning to do both. Although we may decide to be gentle about
> it and
> > > > deprecate the method, but preserve the functionality (which will put a
> bit
> > > > of extra maintenance burden on us).
> > > >
> > > > I am leaning towards the first option (deprecate and stop invoking),
> > > > especially since the nature of the change results in enhanced data
> > > > consistency, so there won't be any unpleasant surprises.
> > > >
> > > > Andrus
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Query.setRefreshingObjects(boolean)
Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually I was going to do the opposite, but since we've set the
backwards compatibility bar for ourselves pretty high in the past, I
guess I am persuaded to go with deprecated-but-don't-cripple approach.
I guess that means also putting a deprecation note in the Modeler next
to refresh checkbox.
Andrus
On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
> I'd like to second the opinion that deprecated still works (until
> removed), but is discouraged from use. I believe that is what Andrus
> intends, though, given previous API changes.
>
> On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger
> <mk...@gmail.com> wrote:
>> I guess my problem is that to me @deprecate means "it still works
>> like
>> it used to, but it won't work in a future version and it's time for
>> you to change your code", but that's not what's going to happen here.
>>
>> That's why if we're not really @deprecating it but crippling it, then
>> I'd recommend removing it. Giving end-users the false-hope that
>> things are working as usual isn't very nice.
>>
>> You know the details of this particular situation better than I do,
>> though. If you don't think silently doing nothing will affect
>> expected program behavior, go for it.
>>
>>
>>
>> On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>>>
>>
>>
>>> On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
>>>
>>>
>>>> To me, that sounded like you were going to change the behavior
>>>> rather
>>>> than just mark the method as @deprecated.
>>>>
>>>
>>> I was planning to do both. Although we may decide to be gentle
>>> about it and
>>> deprecate the method, but preserve the functionality (which will
>>> put a bit
>>> of extra maintenance burden on us).
>>>
>>> I am leaning towards the first option (deprecate and stop invoking),
>>> especially since the nature of the change results in enhanced data
>>> consistency, so there won't be any unpleasant surprises.
>>>
>>> Andrus
>>>
>>>
>>
>
Re: Query.setRefreshingObjects(boolean)
Posted by Michael Gentry <bl...@gmail.com>.
I'd like to second the opinion that deprecated still works (until
removed), but is discouraged from use. I believe that is what Andrus
intends, though, given previous API changes.
On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> I guess my problem is that to me @deprecate means "it still works like
> it used to, but it won't work in a future version and it's time for
> you to change your code", but that's not what's going to happen here.
>
> That's why if we're not really @deprecating it but crippling it, then
> I'd recommend removing it. Giving end-users the false-hope that
> things are working as usual isn't very nice.
>
> You know the details of this particular situation better than I do,
> though. If you don't think silently doing nothing will affect
> expected program behavior, go for it.
>
>
>
> On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> >
>
>
> > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> >
> >
> > > To me, that sounded like you were going to change the behavior rather
> > > than just mark the method as @deprecated.
> > >
> >
> > I was planning to do both. Although we may decide to be gentle about it and
> > deprecate the method, but preserve the functionality (which will put a bit
> > of extra maintenance burden on us).
> >
> > I am leaning towards the first option (deprecate and stop invoking),
> > especially since the nature of the change results in enhanced data
> > consistency, so there won't be any unpleasant surprises.
> >
> > Andrus
> >
> >
>
Re: Query.setRefreshingObjects(boolean)
Posted by Mike Kienenberger <mk...@gmail.com>.
I guess my problem is that to me @deprecate means "it still works like
it used to, but it won't work in a future version and it's time for
you to change your code", but that's not what's going to happen here.
That's why if we're not really @deprecating it but crippling it, then
I'd recommend removing it. Giving end-users the false-hope that
things are working as usual isn't very nice.
You know the details of this particular situation better than I do,
though. If you don't think silently doing nothing will affect
expected program behavior, go for it.
On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
>
>
> > To me, that sounded like you were going to change the behavior rather
> > than just mark the method as @deprecated.
> >
>
> I was planning to do both. Although we may decide to be gentle about it and
> deprecate the method, but preserve the functionality (which will put a bit
> of extra maintenance burden on us).
>
> I am leaning towards the first option (deprecate and stop invoking),
> especially since the nature of the change results in enhanced data
> consistency, so there won't be any unpleasant surprises.
>
> Andrus
>
>
Re: Query.setRefreshingObjects(boolean)
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> To me, that sounded like you were going to change the behavior rather
> than just mark the method as @deprecated.
I was planning to do both. Although we may decide to be gentle about
it and deprecate the method, but preserve the functionality (which
will put a bit of extra maintenance burden on us).
I am leaning towards the first option (deprecate and stop invoking),
especially since the nature of the change results in enhanced data
consistency, so there won't be any unpleasant surprises.
Andrus
Re: Query.setRefreshingObjects(boolean)
Posted by Mike Kienenberger <mk...@gmail.com>.
Maybe I'm simply misunderstanding what you meant by "actually ignoring
it in runtime".
To me, that sounded like you were going to change the behavior rather
than just mark the method as @deprecated.
On 5/5/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> @deprecated is the way we always do it. That's sort of implied.
>
> Andrus
>
>
> On May 5, 2008, at 8:26 PM, Mike Kienenberger wrote:
>
>
> > I don't have any opinion on the actual method involved, but when you
> > remove it, don't have it silently ignore the setting. Either get rid
> > of it completely (so compilation/runtime breaks) or have it continue
> > to function (@deprecated with BIG warnings in the logs).
> >
> > I'd hate to be a developer who misses this in the release notes after
> > upgrading some application, and then tries to figure out why things
> > don't work as expected any more...
> >
> > On 5/3/08, Andrus Adamchik <an...@objectstyle.org> wrote:
> >
> > >
> > > On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote:
> > >
> > >
> > >
> > > > a set of queries with a large # of combinations of parameters, but all
> > > >
> > > searching the same underlying data set that rarely changes
> > >
> > > >
> > > >
> > >
> > > On the other hand, even this example is better served by using query
> cache.
> > > For a marginal increase in memory use, it should give much better access
> > > speed and refresh manageability. So I am out of examples of why
> > > "setRefreshingObjects(false)" is good, but I'll wait for the comments
> before
> > > removing it.
> > >
> > > Andrus
> > >
> > >
> >
> >
>
>
Re: Query.setRefreshingObjects(boolean)
Posted by Andrus Adamchik <an...@objectstyle.org>.
@deprecated is the way we always do it. That's sort of implied.
Andrus
On May 5, 2008, at 8:26 PM, Mike Kienenberger wrote:
> I don't have any opinion on the actual method involved, but when you
> remove it, don't have it silently ignore the setting. Either get rid
> of it completely (so compilation/runtime breaks) or have it continue
> to function (@deprecated with BIG warnings in the logs).
>
> I'd hate to be a developer who misses this in the release notes after
> upgrading some application, and then tries to figure out why things
> don't work as expected any more...
>
> On 5/3/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote:
>>
>>
>>> a set of queries with a large # of combinations of parameters, but
>>> all
>> searching the same underlying data set that rarely changes
>>>
>>
>> On the other hand, even this example is better served by using
>> query cache.
>> For a marginal increase in memory use, it should give much better
>> access
>> speed and refresh manageability. So I am out of examples of why
>> "setRefreshingObjects(false)" is good, but I'll wait for the
>> comments before
>> removing it.
>>
>> Andrus
>>
>
Re: Query.setRefreshingObjects(boolean)
Posted by Mike Kienenberger <mk...@gmail.com>.
I don't have any opinion on the actual method involved, but when you
remove it, don't have it silently ignore the setting. Either get rid
of it completely (so compilation/runtime breaks) or have it continue
to function (@deprecated with BIG warnings in the logs).
I'd hate to be a developer who misses this in the release notes after
upgrading some application, and then tries to figure out why things
don't work as expected any more...
On 5/3/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote:
>
>
> > a set of queries with a large # of combinations of parameters, but all
> searching the same underlying data set that rarely changes
> >
>
> On the other hand, even this example is better served by using query cache.
> For a marginal increase in memory use, it should give much better access
> speed and refresh manageability. So I am out of examples of why
> "setRefreshingObjects(false)" is good, but I'll wait for the comments before
> removing it.
>
> Andrus
>
Re: Query.setRefreshingObjects(boolean)
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote:
> a set of queries with a large # of combinations of parameters, but
> all searching the same underlying data set that rarely changes
On the other hand, even this example is better served by using query
cache. For a marginal increase in memory use, it should give much
better access speed and refresh manageability. So I am out of examples
of why "setRefreshingObjects(false)" is good, but I'll wait for the
comments before removing it.
Andrus