[
https://issues.apache.org/jira/browse/OPENJPA-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131275#comment-18131275
]
ASF subversion and git services commented on OPENJPA-3017:
----------------------------------------------------------
Commit 544e21ceb37315c80c54f90552881e1a9c5d043c in openjpa's branch
refs/heads/OPENJPA-3020 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=544e21ceb ]
[OPENJPA-3017] Map a collection whose converter takes the collection itself
(#220)
* [OPENJPA-3017] Map a collection whose converter takes the collection itself
A converter declared AttributeConverter<List<X>, Y> converts the attribute
as a whole, so the field is basic and maps to one column. It was instead
treated as having no persistence strategy, left out of the mapping, and its
contents were lost without an error.
* [OPENJPA-3017] Use pattern matching for instanceof in
resolveConverterTypeArgument
* [OPENJPA-3017] Put a mapping file column of a basic collection on the
attribute
A <column> inside <basic> on a collection or map was assigned to the
element mapping unless the value was serialized. A collection converted
as a whole then failed to map with "this mapping cannot have columns in
this context". A basic attribute is one value with one column, so its
column now belongs to the attribute. The converter cannot decide this
here, since an @Convert annotation is not parsed yet.
* [OPENJPA-3017] Fetch a collection converted as a whole eagerly by default
A converted attribute is basic, and a basic attribute is eager unless it
is declared lazy. A collection or map converted as a whole fell back to the
lazy default of collections, so it was not loaded before detach.
* [OPENJPA-3017] Note converted collections in the migration considerations
> @Convert on a collection attribute is ignored and the attribute is silently
> not persisted
> -----------------------------------------------------------------------------------------
>
> Key: OPENJPA-3017
> URL: https://issues.apache.org/jira/browse/OPENJPA-3017
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 4.1.1
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> An {{@Convert}} annotation on a collection-valued attribute is not honoured,
> and the attribute is silently excluded from the mapping. Neither an exception
> nor an error is raised, and the data is lost without notice.
> Reduced case: an entity declaring
> {code:java}
> @Convert(converter = ItemListConverter.class)
> private List<Item> items = new ArrayList<>();
> {code}
> where {{ItemListConverter}} implements {{AttributeConverter<List<Item>,
> String>}} and {{Item}} is a plain bean. Observed behaviour on 4.2.0-SNAPSHOT
> with Derby:
> * {{ClassMapping.getField("items")}} returns {{null}}, so the field is not a
> managed field at all;
> * no column is generated for it;
> * a {{persist()}} followed by a {{find()}} in a fresh context returns an
> empty list, with no exception at any point;
> * the sole trace is one warning stating that the field is "not a default
> persistent type, and do not have any annotations indicating their persistence
> strategy", from which it follows that {{@Convert}} is not counted as an
> indication of a persistence strategy. In a run of the full test suite several
> hundred such warnings are emitted, so the one that matters is easily missed.
> Two defects follow. First, {{@Convert}} should be recognised as declaring a
> persistence strategy. Second, where the conversion cannot be applied, the
> attribute must not be dropped in silence; an error naming the attribute and
> the reason is required.
> On the specified semantics: {{@Convert}} applied to a collection attribute
> other than a {{Map}}, with no {{attributeName}}, converts the *elements* of
> the collection, which would require {{AttributeConverter<Item, ?>}} together
> with {{@ElementCollection}}. A converter whose attribute type is the
> collection itself, mapping the whole collection to a single column, is a
> provider extension; Hibernate admits it. Whichever reading is implemented,
> the present behaviour is wrong, because an unsupported mapping is accepted
> and then ignored.
> Reported on the development list by Francesco Chicchiriccò while testing
> Apache Syncope master against 4.2.0-SNAPSHOT. In that configuration the
> attribute is managed and the failure is instead
> {noformat}
> org.apache.openjpa.util.MetaDataException: You have supplied columns for
> "...JPARealm.plainAttrs<element:class ...PlainAttr>", but this mapping cannot
> have columns in this context.
> at
> org.apache.openjpa.jdbc.meta.MappingInfo.assertNoSchemaComponents(MappingInfo.java:384)
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.map(HandlerFieldStrategy.java:84)
> {noformat}
> which arises because the handler derived from the converter is installed and
> the element mapping is then found to carry columns. That path did not
> reproduce from the annotations alone, neither with a {{Serializable}} element
> type nor with a non-final field, and the configuration difference is still to
> be established. The message is in any case opaque with respect to the cause.
> A workaround exists and was verified: the converted form serves as the
> persistent attribute, that is a {{String}} column holding the serialised
> value, the collection is marked {{@Transient}}, and the two directions are
> carried out in {{@PrePersist}}/{{@PreUpdate}} and {{@PostLoad}}. The OpenJPA
> extensions {{@Externalizer}} and {{@Factory}} offer no alternative, as
> {{@Persistent}} rejects a field of {{List}} type.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
