Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Query.setRefreshingObjects(boolean)
Date: Tue, 6 May 2008 12:44:40 -0400
Message-ID: 
 <8F798BFDA851B943B3A1B2510E92878508247427@airmail.wirelessworld.airvananet.com>
In-Reply-To: <8f985b960805051521v55af403te4e914f8949730d2@mail.gmail.com>
Thread-Topic: Query.setRefreshingObjects(boolean)
Thread-Index: Aciu/nNltXNhirb9SZetinpmnEt5QgAmd4Xg
References: <A8063296-FF11-47BF-96A0-D623B893EB8F@objectstyle.org>
 <8f985b960805051026r4cacb693mad12ac6aac284cdb@mail.gmail.com>
 <71F760C2-74D7-4AC3-950D-9BC0BFC26E31@objectstyle.org>
 <8f985b960805051239o51827d32xc691b63b664491e8@mail.gmail.com>
 <5DAE4A05-4414-4308-8F87-FDFEB9B00313@objectstyle.org>
 <8f985b960805051302w289636a0k865244134d4f2a5b@mail.gmail.com>
 <f65b8ae30805051336k3098b4ffo7862b7e3067ee804@mail.gmail.com>
 <C32DF9FE-74BD-40C4-A3A7-825EC431B0FA@objectstyle.org>
 <8f985b960805051400p350110e0x6acd009af6e3b53a@mail.gmail.com>
 <8F798BFDA851B943B3A1B2510E928785082472A0@airmail.wirelessworld.airvananet.com>
 <8f985b960805051521v55af403te4e914f8949730d2@mail.gmail.com>
From: "Scott Anderson" <sanderson@airvana.com>
To: <user@cayenne.apache.org>

Of course, how could I forget!

Regardless, what's the point of providing API that compiles and then
ambiguously breaks?=20

-----Original Message-----
From: Mike Kienenberger [mailto:mkienenb@gmail.com]=20
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 <sanderson@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 <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
>  > > > >
>  > > > >
>  > > > >
>  > > >
>  > > >
>  > >
>  > >
>  >
>  >
>