incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart (JIRA)" <>
Subject [jira] Resolved: (GRFT-103) AtomicTypeConversion on retrieve omitted (fails) when NodeTypePerHierarchy && Discriminator
Date Wed, 18 Oct 2006 19:27:36 GMT
     [ ]

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 &&
> -------------------------------------------------------------------------------------------
>                 Key: GRFT-103
>                 URL:
>             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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message