[
https://issues.apache.org/jira/browse/OPENJPA-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141838#comment-18141838
]
ASF subversion and git services commented on OPENJPA-2944:
----------------------------------------------------------
Commit 4d085a1d719d6d76231a7bf24716b5724e2a1026 in openjpa's branch
refs/heads/OPENJPA-2944 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=4d085a1d7 ]
[OPENJPA-2944] Describe the previous converter mapping as 4.1.x had it
OpenJPA 4.1.x had no converter type resolution and ignored autoApply: the
column of every converted attribute followed the attribute type. The
migration considerations, the Compatibility Javadoc, the upgrade note and
the code comments compared against the unreleased 4.2.0 development state
instead. They now say that ResolveConverterTypeHierarchy=false restores the
4.1.x mapping for attributes whose converter declares its types through a
generic superclass or interface, and that the general converter changes
described under "AttributeConverter handling" are not affected by it.
> Inconsistent column type conversion when using AttributeConverter
> -----------------------------------------------------------------
>
> Key: OPENJPA-2944
> URL: https://issues.apache.org/jira/browse/OPENJPA-2944
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 4.1.0
> Environment: Postgresql
> Reporter: Guenter Windsperger
> Priority: Minor
>
> When using an AttributeConverter the resulting expression is always of type
> `bytea` instead of the respective declared converter type e.g. bigint for
> Long.
> This can be observed with the existing Test `TestExternalValues`, where both
> UUID properties, one converted with the custom Externalizer API, the other
> with the standard Converter API, produce different column types.
> I am happy to provide some PR if someone could point me to the potential root
> cause.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
