Sounds like a good idea to me. I can't think of any downsides other than that it will be harder to read the data structure when debugging.
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
