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
