That sounds like a reasonable compromise to me. In that case, a couple API
additions that return/set the enum type may be nice. I'd have to see what
it would do to the API overall though.
-- KevinOn 11/27/07 12:58 PM, "Andrus Adamchik" <andru..bjectstyle.org> wrote:
> 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 >> >> >
-- 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 : Thu Nov 29 2007 - 11:18:49 EST