cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lindesay <...@lindesay.co.nz>
Subject Read Property Behaviour (CAY-1512)
Date Wed, 17 Nov 2010 18:12:44 GMT
Hello;

I've been playing around with trying to override some behaviours in the 
area of "read property" on the data objects, but I think I have come to 
the conclusion that the way it is rigged-up makes this a little 
difficult.  I'd like to suggest a change (which is probably more 
appropriate for 3.1 owing to it being a non-trivial change in behaviour) 
and I would be interested in any feedback.  Here is the text of the 
ticket...

---

There is an issue that a data object (DO) uses the "readProperty()" 
method in its accessors such as "getStartTimestamp()"/"getArtist()" 
etc... The "readNestedProperty()" does some extra things like using 
reflection to get at non-modelled accessors, but "readProperty()" does 
not.  This is an inconsistency.

Simply adding the additional reflection to "readProperty()" is not a 
good idea because in the case where an object is not yet related to the 
model, an infinite loop can result.  Particularly in the case where a 
data object is not yet added to an object context, the logical condition 
around stopping this infinite loop is not able to be identified.

My suggestion is to add a protected "readPropertyStored()" which will be 
used by the accessors such as "getStartTimestamp()"/"getArtist()".  This 
method will ~not~ use reflection, but "readProperty()" will do the 
additional reflection if necessary.  The "readPropertyStored()" will 
continue to invoke "readPropertyDirectly()".

In addition, the "extra reflection" from "readProperty()" would be 
serviced through two additional methods on the data object;

      readPropertyDerived(..)

For the case of the "readNestedProperty(..)" the use of reflection into 
an object which is ~not~ a data object will be serviced through;

      readNestedPropertyFromNonDataObject(..)
	
Together these changes will allow for consistenecy in the 'read 
property' behaviour and will also allow third parties to more easily 
extend Cayenne's 'read property' behaviors in order to support more 
sophisticated 'read property' behaviour.

This is a change in behavior and generated DAO classes would need to be 
modified to use 'readPropertyStored()' instead of 'readProperty()'.

---

cheers.

-- 
Andrew Lindesay
www.silvereye.co.nz

Mime
View raw message