Are you planning on still supporting key paths (readProperty, readNestedProperty, etc)?
Also, I'm assuming the constants for the array index would be generated in the _Class. We might need to look into the serialVersionUID issue again, too, because this seems more fragile between versions to me. Thanks, mrg On Fri, Oct 25, 2013 at 9:13 AM, Andrus Adamchik <and...@objectstyle.org>wrote: > Been thinking about it for a long time. Now finally had a quiet vacation > moment to put my thoughts in an email.. This is about CayenneDataObject > structure (or rather an alternative to it). Each CDO is really a wrapper > around a HashMap. A HashMap gives flexibility to store anything we want, > but it is also a heavy and thread-unsafe structure. One of the reasons we > designed ivar-based PersistentObject for ROP was to avoid sending > serialized HashMaps across the wire. However ivar-based design has its own > shortcomings in an ORM. E.g. you can't store faults in ivars of a fixed > type. Also keeping the entire object state in one data structure that is > not a DO itself will allow to implement some other improvements I am > considering (this is a topic of another discussion - I am thinking of > atomically swapping object state to improve DataContext select concurrency) > > So I am thinking of creating an entirely new DataObject superclass based > on fixed-size array with properties accessed by numeric index. The idea is > similar to java.util.EnumMap: A set of persistent properties for each > entity is known and fixed. Sorting properties alphabetically gives us an > index of each value in the object values array. This index can be stored in > property descriptors, and used in generated object code. Array-based > DataObject will have the following properties/advantages: > > * It is internally consistent without any synchronization, i.e. unlike > HashMap it won't fall apart when modified by multiple threads. > * It is compact. Unlike HashMap there's no Entry<K,V> objects, and no > multi-bucket strcuture. As a result each DataObject will take less memory, > and produce smaller serialized footprint. > * User-facing getters and setters will work faster - array element access > by index vs. a HashMap get. > * Don't see any reason why we can't use it on the ROP client, so we may > achieve our long-term goal of unifying client and server stacks. > * Object state can be cloned in a consistent manner and can be swapped > atomically - something that may be important for the future context > concurrency work. > > Comments are welcome. > > Andrus
