cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: array-based DataObject
Date Fri, 25 Oct 2013 15:17:16 GMT
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.



On Fri, Oct 25, 2013 at 9:13 AM, Andrus Adamchik <>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

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