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" <[EMAIL PROTECTED]>
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
