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..eprecated.
On 5/5/08, Andrus Adamchik <andru..bjectstyle.org> wrote:
>..eprecated 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 ..eprecated 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 <andru..bjectstyle.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
> > >
> > >
> >
> >
>
>
This archive was generated by hypermail 2.0.0 : Mon May 05 2008 - 15:40:27 EDT