You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrew Lindesay (JIRA)" <ji...@apache.org> on 2010/11/17 18:59:14 UTC
[jira] Created: (CAY-1512) Change in Behaviour with "Read Property"
Methods
Change in Behaviour with "Read Property" Methods
------------------------------------------------
Key: CAY-1512
URL: https://issues.apache.org/jira/browse/CAY-1512
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 additional 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, the reflection can end up infinite-looping and it is hard to see a logical condition to stop it.
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 invoke "readPropertyDirectly()".
In addition, the "extra reflection" 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' behaviours in order to support more sophisticated 'ready property' behaviour.
This is a change in behaviour 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.
[jira] [Closed] (CAY-1512) Change in Behaviour with "Read Property"
Methods
Posted by "Andrew Lindesay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Lindesay closed CAY-1512.
--------------------------------
Resolution: Not A Problem
Hi Andrus; Actually I have worked around this along the lines of discussion on the mailing list. So I will close this ticket and if anybody else opens something like this then they can re-open a new ticket.
> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>
> Key: CAY-1512
> URL: https://issues.apache.org/jira/browse/CAY-1512
> Project: Cayenne
> Issue Type: Improvement
> Components: Core Library
> Affects Versions: 3.0
> Reporter: Andrew Lindesay
> Fix For: 3.0.3
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CAY-1512) Change in Behaviour with "Read
Property" Methods
Posted by "Andrew Lindesay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933061#action_12933061 ]
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.
cheers.
> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>
> Key: CAY-1512
> URL: https://issues.apache.org/jira/browse/CAY-1512
> 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.
[jira] [Updated] (CAY-1512) Change in Behaviour with "Read
Property" Methods
Posted by "Andrus Adamchik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrus Adamchik updated CAY-1512:
---------------------------------
Fix Version/s: (was: 3.0.2)
3.0.3
> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>
> Key: CAY-1512
> URL: https://issues.apache.org/jira/browse/CAY-1512
> Project: Cayenne
> Issue Type: Improvement
> Components: Core Library
> Affects Versions: 3.0
> Reporter: Andrew Lindesay
> Fix For: 3.0.3
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CAY-1512) Change in Behaviour with "Read Property"
Methods
Posted by "Andrew Lindesay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Lindesay updated CAY-1512:
---------------------------------
Description:
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 additional 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, the reflection can end up infinite-looping and it is hard to see a logical condition to stop it.
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 invoke "readPropertyDirectly()".
In addition, the "extra reflection" 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' behaviours in order to support more sophisticated 'ready property' behaviour.
This is a change in behaviour and generated DAO classes would need to be modified to use 'readPropertyStored()' instead of 'readProperty()'.
was:
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 additional 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, the reflection can end up infinite-looping and it is hard to see a logical condition to stop it.
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 invoke "readPropertyDirectly()".
In addition, the "extra reflection" 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' behaviours in order to support more sophisticated 'ready property' behaviour.
This is a change in behaviour and generated DAO classes would need to be modified to use 'readPropertyStored()' instead of 'readProperty()'.
> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>
> Key: CAY-1512
> URL: https://issues.apache.org/jira/browse/CAY-1512
> 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 additional 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, the reflection can end up infinite-looping and it is hard to see a logical condition to stop it.
> 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 invoke "readPropertyDirectly()".
> In addition, the "extra reflection" 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' behaviours in order to support more sophisticated 'ready property' behaviour.
> This is a change in behaviour 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.
[jira] Commented: (CAY-1512) Change in Behaviour with "Read
Property" Methods
Posted by "Andrus Adamchik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933057#action_12933057 ]
Andrus Adamchik commented on CAY-1512:
--------------------------------------
Andrew, I don't quite follow what problem are we solving in this Jira?
> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>
> Key: CAY-1512
> URL: https://issues.apache.org/jira/browse/CAY-1512
> 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 additional 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, the reflection can end up infinite-looping and it is hard to see a logical condition to stop it.
> 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 invoke "readPropertyDirectly()".
> In addition, the "extra reflection" 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' behaviours in order to support more sophisticated 'ready property' behaviour.
> This is a change in behaviour 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.
[jira] Updated: (CAY-1512) Change in Behaviour with "Read Property"
Methods
Posted by "Andrew Lindesay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Lindesay updated CAY-1512:
---------------------------------
Description:
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()'.
was:
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 additional 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, the reflection can end up infinite-looping and it is hard to see a logical condition to stop it.
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 invoke "readPropertyDirectly()".
In addition, the "extra reflection" 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' behaviours in order to support more sophisticated 'ready property' behaviour.
This is a change in behaviour and generated DAO classes would need to be modified to use 'readPropertyStored()' instead of 'readProperty()'.
> Change in Behaviour with "Read Property" Methods
> ------------------------------------------------
>
> Key: CAY-1512
> URL: https://issues.apache.org/jira/browse/CAY-1512
> 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.