> Are you planning on still supporting key paths (readProperty, > readNestedProperty, etc)?
Yeah, most certainly. > 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. Right, good point. The array size may vary from version to version. Andrus On Oct 25, 2013, at 6:17 PM, Michael Gentry <[email protected]> wrote: > 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 > <[email protected]>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
