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
