Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Andrus Adamchik <andrus@objectstyle.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: array-based DataObject
Message-Id: <F2CD4585-A7DE-4A50-8DAB-587B3980988E@objectstyle.org>
Date: Fri, 25 Oct 2013 16:13:05 +0300
To: "dev@cayenne.apache.org" <dev@cayenne.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))

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)=20

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=