cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Anderson" <sander...@airvana.com>
Subject RE: Query.setRefreshingObjects(boolean)
Date Mon, 05 May 2008 22:14:49 GMT
> 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 <andrus@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
<mkienenb@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 <andrus@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
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Mime
View raw message