Also the users expect things to (mostly) work without code changes
after upgrading a Cayenne jar. And this has been one of the strong
points of Cayenne for many years. We received many praises about the
ease of upgrade between major versions, and I don't want us to turn
into ... ok, I won't be calling names of specific projects that
completely rewrite their API from release to release, we all know them
well :-) Now I am guilty myself of removing/changing stable API on a
short notice occasionally, but generally we've been pretty good at
keeping things backwards compatible and setting up proper deprecation
period.
So how about this - we can change internal implementation of
CayenneDataObject and PersistentObject to actually store an enum field
for state, but we still preserve the int methods with deprecated tag,
returning enum ordinal? I think that's reasonable and addresses your
concern about debugging.
Andrus
On Nov 27, 2007, at 7:37 PM, Kevin Menard wrote:
> I'm not sure that our users are looking for more time. While
> certainly
> there are benefits by Cayenne's internals switching to Java 5, such
> as the
> use of the new concurrent API, I'd imagine for a lot of users the
> benefit of
> the move is the use of generics, enums, etc. Taking the
> PersistenceState
> for example . . . As an enum, this would save me a lot of
> development time.
> I can't count how many times I've looked at an object in a debugger
> and
> wasn't clear on the static int value for the persistence state and
> didn't
> want to have to keep typing persistenceStateName() to find out.
>
> I've also run across code where things get casted to the wrong type
> and the
> modified newObject() takes care of that problem.
>
> Anyway, the picture I'm trying to paint is that the code modifications
> necessary are minimal in comparison to the time that could be saved by
> making them. This is the feeling I was getting off the user list as
> well.
> Without going too far out on a limb, either, I'd imagine many are
> using the
> milestones as a migratory period as well.
>
> On 11/27/07 12:20 PM, "Andrus Adamchik" <andru..bjectstyle.org>
> wrote:
>
>>
>> On Nov 27, 2007, at 7:05 PM, Kevin Menard wrote:
>>
>>> While we could use enums internally and preserve the int based API
>>> for
>>> client use, it seems to be of dubious value. We could deprecate it
>>> now I
>>> suppose, but introducing a new alternative to PersistenceState, that
>>> encodes
>>> the same info, just in a nicer manner, doesn't appear to gain us
>>> much.
>>
>> It gives the users more time (maybe a year, maybe more) to migrate
>> their code and a clear indication of what will be changed.
>>
>>> FWIW, the change to performQuery to return List<?> broke more of my
>>> code
>>> than the enum changes would.
>>
>> That's a good one... Impact of generics conversion on backwards
>> compatibility is not fully clear to me just yet. There is a
>> possibility that we may need to undo some of what we've done with it.
>>
>> Andrus
>
> --
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for network equipment
> www.servprise.com +1 508.892.3823 x308
>
>
This archive was generated by hypermail 2.0.0 : Tue Nov 27 2007 - 12:58:53 EST