cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Razumovsky <>
Subject Re: Plans for the future (aka 3.1 roadmap)
Date Thu, 19 Nov 2009 13:11:52 GMT
OK, lets do this in several steps. The first step would be eliminating
difference between client (PersistentObject) and server (CDO). This also is
part of major goal of eliminating superclass.
In my view this first step is:
1. Moving methods from CDO up to PersistentObject, making PersistentObject
implement DataObject.
2. Eliminating what we can from DO interface ("snapshotVersions"?)
3. Making sure client classes now can act as server classes WITHOUT any
change (i.e. if they extend PersistentObject).
4. Deprecating CDO and start using current client VM's instead of server
After that, we can :
5. remove all usages of Property, add/removeToManyTarget etc
from server code. Ensure DO interface is not used internally. it will make
the only imperative that classes implement Persistent

2009/11/19 Andrus Adamchik <>

> No question, this can be useful. Where this gets in the way is with our
> elusive goal of providing persistence for POJOs without a framework-mandated
> superclass.
> The good news is that ClassDescriptor design can accommodate any type of
> objects (as long as you can force it to use ObjectContext callbacks). So
> while it is beneficial to eliminate object structural gap between ROP and
> "normal" Cayenne, it looks like support of separate hierarchies of POJOs
> (preferably without framework superclass), and generic objects is in our
> future (unless we totally give up on the POJO idea and keep extending
> CayenneDataObject everywhere).
> Now, if we do support both types of objects across the entire stack, it
> will be a user's choice what to inherit from (and as a result either use
> read/writeProperty methods or not).
> Andrus
> On Nov 19, 2009, at 1:12 PM, Andrey Razumovsky wrote:
>> 2009/11/19 Andrus Adamchik <>
>>  Also Cayenne's own object access since 3.0 is fully based on pluggable
>>> ClassDescriptors, so declaring read/writeProperty on the object is not
>>> needed for Cayenne, and technically only the generic objects need such
>>> user-facing methods.
>> For that, I'll disagree. I've used a lot in
>> my
>> code for unified processing of DataObjects (non-generic) and prefer those
>> method stay in interface (moreover, appear in client-side objects). Vice
>> versa, read/writeProperty methods should through ClassDescriptors


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message