You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by "Dan Connelly (JIRA)" <ji...@apache.org> on 2006/09/24 12:56:22 UTC
[jira] Created: (GRFT-106) Avoid INFINITE RECURSION when Object
Model has cycles.
Avoid INFINITE RECURSION when Object Model has cycles.
------------------------------------------------------
Key: GRFT-106
URL: http://issues.apache.org/jira/browse/GRFT-106
Project: Graffito
Issue Type: Improvement
Components: JCR-Mapping
Reporter: Dan Connelly
Priority: Critical
The default ObjectConverterImpl is restricted to acyclic graphs in the object model.
Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles.
Saving an Object Model that contains cycles using Graffito causes an infinite recursion.
Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE., Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa.
Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node. This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First.
Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-106) Avoid INFINITE RECURSION when Object
Model has cycles.
Posted by "Dan Connelly (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-106?page=comments#action_12437212 ]
Dan Connelly commented on GRFT-106:
-----------------------------------
The use of UNDEFINED would also affect the selection of the default or custom ProxyManager.
UNDEFINED Beans and collection Items might be translated to Proxies that execute a lookup based on some Path Conversion scheme. The Path Conversions could be either stored in the Repository or provided by a custom ProxyManager.
> Avoid INFINITE RECURSION when Object Model has cycles.
> ------------------------------------------------------
>
> Key: GRFT-106
> URL: http://issues.apache.org/jira/browse/GRFT-106
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Priority: Critical
>
> The default ObjectConverterImpl is restricted to acyclic graphs in the object model.
> Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles.
> Saving an Object Model that contains cycles using Graffito causes an infinite recursion.
> Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE., Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa.
> Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node. This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First.
> Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GRFT-106) Avoid INFINITE RECURSION when Object
Model has cycles.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GRFT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christophe Lombart reassigned GRFT-106:
---------------------------------------
Assignee: Christophe Lombart
> Avoid INFINITE RECURSION when Object Model has cycles.
> ------------------------------------------------------
>
> Key: GRFT-106
> URL: https://issues.apache.org/jira/browse/GRFT-106
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Assigned To: Christophe Lombart
> Priority: Critical
>
> The default ObjectConverterImpl is restricted to acyclic graphs in the object model.
> Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles.
> Saving an Object Model that contains cycles using Graffito causes an infinite recursion.
> Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE., Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa.
> Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node. This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First.
> Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GRFT-106) Avoid INFINITE RECURSION when Object
Model has cycles.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-106?page=comments#action_12443528 ]
Christophe Lombart commented on GRFT-106:
-----------------------------------------
* What about the auto* settings (auto-retrieve,auto-update & auto-insert). Those settings can limit graph load and updates ?
* Reference is not supported but we can also use the auto* settings.
> Avoid INFINITE RECURSION when Object Model has cycles.
> ------------------------------------------------------
>
> Key: GRFT-106
> URL: http://issues.apache.org/jira/browse/GRFT-106
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Priority: Critical
>
> The default ObjectConverterImpl is restricted to acyclic graphs in the object model.
> Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles.
> Saving an Object Model that contains cycles using Graffito causes an infinite recursion.
> Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE., Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa.
> Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node. This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First.
> Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GRFT-106) Avoid INFINITE RECURSION when Object
Model has cycles.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GRFT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christophe Lombart resolved GRFT-106.
-------------------------------------
Resolution: Fixed
Fix Version/s: ocm-1.0
Solve by using an object cache. This is not yet a complete cache system but this small cache is used per persistenceManager and only for retrieve requests. It allows to perform circular lookups (as by crossreferenced objects) that would result in non-terminating loops without such a cache.
Later I would like to implement a complete object cache support. Something like in Hibernate or OJB. There is a good description here : http://db.apache.org/ojb/docu/guides/objectcache.html. I think we have similar needs but we have to define a proposal for this kind of feature with the most useful use cases.
> Avoid INFINITE RECURSION when Object Model has cycles.
> ------------------------------------------------------
>
> Key: GRFT-106
> URL: https://issues.apache.org/jira/browse/GRFT-106
> Project: Graffito
> Issue Type: Improvement
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Assigned To: Christophe Lombart
> Priority: Critical
> Fix For: ocm-1.0
>
>
> The default ObjectConverterImpl is restricted to acyclic graphs in the object model.
> Many Java object models are NOT acyclic. For instance, I am on your Friends list. Yoar are on my Friends list. Java encourages such structures. Almost any large object model in Java will have hidden cycles.
> Saving an Object Model that contains cycles using Graffito causes an infinite recursion.
> Clearly, it is important to maintain a 1-to-1 correspondence between Nodes and Objects to prevent this. In the absence of Multiple Parent Nodes, it will be necessary to use REFERENCE or UNDEFINED Items in place of the 2nd (or greater) Node representing a given Object. My preference si that the default ObjectConverterImpl should support REFERENCE., Failing this, use of UNDEFINED also solves this problem and would acceptable (as default). Whether or not REFERENCE is used, both insertion and retrieval must provide a reasonable result. A custom ojbect converter should be available to switch UNDEFINED to REFERENCE, or vice versa.
> Also, it is probably best to keep the targeted, well-defined Nodes close to the Root Node. This implies that the default ObjectConverterImpl should implement a Breadth-First, rather than a Depth-First, traversal of the Object Model on both insertion and retrieval. Again, if the default is Depth-First, a custom object converter should be available that implements Breadth-First.
> Admittedly, support for (2 representations) X (2 traversals) implies a drastic refactoring and/or rewriting of the ObjectConverterImpl class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.