[ 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
