cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Query.setRefreshingObjects(boolean)
Date Mon, 05 May 2008 20:47:14 GMT
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.


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

View raw message