cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Lindesay (JIRA)" <>
Subject [jira] Commented: (CAY-1512) Change in Behaviour with "Read Property" Methods
Date Wed, 17 Nov 2010 18:17:14 GMT


Andrew Lindesay commented on CAY-1512:

Hi Andrus;

Two problems;

1) the readNestedProperty uses reflection and readProperty does not.  The fact that it's nested
shouldn't really influence the ability to use the reflection behaviours.  The get... methods
from the modelled attributes and relationships use "readProperty()" and so they should _not_
be doing reflection and so to introduce reflection behaviour into "readProperty()" I would
like to add a lower-level, protected method which the accessors use which resolves the fault
still, but doesn't do the reflection behaviour.

2) The reflection behaviour is on a static class method directly and there's no means to override/subvert
the 'I can't find the property' behaviour.  I would like to add methods to proxy that behaviour
so that it can be overriden/subverted.


> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>                 Key: CAY-1512
>                 URL:
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.0
>            Reporter: Andrew Lindesay
>             Fix For: 3.0.2
> 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 'ready property' behaviour.
> This is a change in behavior and generated DAO classes would need to be modified to use
'readPropertyStored()' instead of 'readProperty()'.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message