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: domain of mkienenb@gmail.com designates
 74.125.46.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Hv3xKZKLh7+EI5daNed1LIFUQg1roq8scEE1JQGhfQL3EydSru2j+KuXVK9XYN2ay6ODu80PTZsm5C5Ss6+1kPDyT54JkreU8X8W9spo4okER3P8bm7wzn/xkCbPipM7fp6mHyWLVAAqAQ6R9niJ/mXXgYhAF3NlLRfeMTbdXlw=
Message-ID: <8f985b960805051400p350110e0x6acd009af6e3b53a@mail.gmail.com>
Date: Mon, 5 May 2008 17:00:31 -0400
From: "Mike Kienenberger" <mkienenb@gmail.com>
To: user@cayenne.apache.org
Subject: Re: Query.setRefreshingObjects(boolean)
In-Reply-To: <C32DF9FE-74BD-40C4-A3A7-825EC431B0FA@objectstyle.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <A8063296-FF11-47BF-96A0-D623B893EB8F@objectstyle.org>
	 <318AF1B8-3688-4EC9-A6E3-AAF4DF70BD2A@objectstyle.org>
	 <376F19A9-4578-4569-864D-33033E3C89A9@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>

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
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>