cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: Field-based Persistent
Date Wed, 29 Feb 2012 15:40:14 GMT
On Wed, Feb 29, 2012 at 1:47 AM, Andrus Adamchik <andrus@objectstyle.org>wrote:

> So changing the topic, and taking to dev...
>
> On Feb 29, 2012, at 7:34 AM, John Huss wrote:
>
> > My entity classes use explicit fields to store data instead of a Map, so
> > when it tries to access the "runtimeRelationshipX" fields
>
> So these are on the server side (not the ROP client)? Did you write your
> own set of ClassDescriptors?
>

Both.  I use the same classes for both server and client because that is
really necessary for my use case.  It takes the ROP approach as a starting
point and adds back in the things you usually get from the server:
1) validation
2) change tracking

So I have a PersistentObject subclass called UniversalObject that adds the
snapshotVersion (which may be unnecessary), the validation methods, and
abstract methods for readPropertyDirectly and writePropertyDirectly.

I have a ValueHolderDescriptorFactory subclass that allows me to use a
subclass of SimpleAttributeProperty that takes care of
calling getObjectContext().propertyChanged on write.

This is hard to describe and hard to follow I'm sure.  When I have time I
can provide a minimal example if you want.


>
> I am working on improving the concurrency of a single DataContext
> (scenario being a single shared context in read-only apps), the Map
> structure of CayenneDataObject is one of the factors causing grief. So I am
> interested in discussing alternative implementations. One being field-based
> objects similar to ROP, another being using an Object[] instead of a Map to
> store mapped properties. Yet another - using a delegate for each Persistent
> (this will also let us drop a common superclass requirement).


It would be nice to have a standard API for how values are written and read
from the Objects, like DataObject.  It is easier (or at least more obvious)
to implement the interface than to try to tweak the descriptors.  That
would make it easier to try alternative approaches.

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