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/19 08:51:22 UTC
[jira] Created: (GRFT-103) AtomicTypeConversion on retrieve omitted
(fails) when NodeTypePerHierarchy && Discriminator
AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy && Discriminator
-------------------------------------------------------------------------------------------
Key: GRFT-103
URL: http://issues.apache.org/jira/browse/GRFT-103
Project: Graffito
Issue Type: Bug
Components: JCR-Mapping
Reporter: Dan Connelly
Priority: Critical
ObjectConverterImpl#retrieveSimpleFields has this guard for one branch of its logic: for populating the retrieved object:
if (classDescriptor.usesNodeTypePerHierarchyStrategy() && classDescriptor.hasDiscriminator())
When this test is true, then there is *no type conversion* on fields. The code attempts to set object field directly from the string, getValue().getString(), value for the node property. This fails for an "int" field mapped from the object.
If I force this test the *false*, then the retrieve works and there is no failure.
While it is not entirely clear to me how the inheritance maaping strategy is chosen or how it is implemented, it does not seem reasonable that the strategy selection should affect field conversions.
In my code, the same mapping file is used for the write and the read whatever variations in mapping I choose.
One variation I have tried is to remove all extend="xxxx" class attributes in the mapping. However, he inheritance strategy remained at NodeTypePerHiearchy and the retrieve continued to fail.
BTW: The DTD comment says "extends" but the !ATTLIST requires it to be "extend". Confusing. Since "extend" is optional and not ambiguous, why would I ever want to provide it in the mapping?
--
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-103) AtomicTypeConversion on retrieve
omitted (fails) when NodeTypePerHierarchy && Discriminator
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-103?page=all ]
Christophe Lombart resolved GRFT-103.
-------------------------------------
Resolution: Fixed
Fixed. I reviewed the method retrieveSimpleFields in order to support a better type convertion. I added this case in the unit test. Let me know if something is wrong.
> AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy && Discriminator
> -------------------------------------------------------------------------------------------
>
> Key: GRFT-103
> URL: http://issues.apache.org/jira/browse/GRFT-103
> Project: Graffito
> Issue Type: Bug
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Assigned To: Christophe Lombart
> Priority: Critical
>
> ObjectConverterImpl#retrieveSimpleFields has this guard for one branch of its logic: for populating the retrieved object:
> if (classDescriptor.usesNodeTypePerHierarchyStrategy() && classDescriptor.hasDiscriminator())
> When this test is true, then there is *no type conversion* on fields. The code attempts to set object field directly from the string, getValue().getString(), value for the node property. This fails for an "int" field mapped from the object.
> If I force this test the *false*, then the retrieve works and there is no failure.
> While it is not entirely clear to me how the inheritance maaping strategy is chosen or how it is implemented, it does not seem reasonable that the strategy selection should affect field conversions.
> In my code, the same mapping file is used for the write and the read whatever variations in mapping I choose.
> One variation I have tried is to remove all extend="xxxx" class attributes in the mapping. However, he inheritance strategy remained at NodeTypePerHiearchy and the retrieve continued to fail.
> BTW: The DTD comment says "extends" but the !ATTLIST requires it to be "extend". Confusing. Since "extend" is optional and not ambiguous, why would I ever want to provide it in the mapping?
--
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-103) AtomicTypeConversion on retrieve
omitted (fails) when NodeTypePerHierarchy && Discriminator
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-103?page=all ]
Christophe Lombart reassigned GRFT-103:
---------------------------------------
Assignee: Christophe Lombart
> AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy && Discriminator
> -------------------------------------------------------------------------------------------
>
> Key: GRFT-103
> URL: http://issues.apache.org/jira/browse/GRFT-103
> Project: Graffito
> Issue Type: Bug
> Components: JCR-Mapping
> Reporter: Dan Connelly
> Assigned To: Christophe Lombart
> Priority: Critical
>
> ObjectConverterImpl#retrieveSimpleFields has this guard for one branch of its logic: for populating the retrieved object:
> if (classDescriptor.usesNodeTypePerHierarchyStrategy() && classDescriptor.hasDiscriminator())
> When this test is true, then there is *no type conversion* on fields. The code attempts to set object field directly from the string, getValue().getString(), value for the node property. This fails for an "int" field mapped from the object.
> If I force this test the *false*, then the retrieve works and there is no failure.
> While it is not entirely clear to me how the inheritance maaping strategy is chosen or how it is implemented, it does not seem reasonable that the strategy selection should affect field conversions.
> In my code, the same mapping file is used for the write and the read whatever variations in mapping I choose.
> One variation I have tried is to remove all extend="xxxx" class attributes in the mapping. However, he inheritance strategy remained at NodeTypePerHiearchy and the retrieve continued to fail.
> BTW: The DTD comment says "extends" but the !ATTLIST requires it to be "extend". Confusing. Since "extend" is optional and not ambiguous, why would I ever want to provide it in the mapping?
--
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