[
https://issues.apache.org/jira/browse/OPENJPA-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ancoron Luciferis updated OPENJPA-2551:
---------------------------------------
Attachment: OPENJPA-2551-trunk.patch
Attached a patch for trunk: [^OPENJPA-2551-trunk.patch]
This patch changes the default mapping from the Java type boolean to SQL-99
standard data type BOOLEAN when supported by the corresponding database.
Also, conversion should be done properly when an existing database is used that
uses data type {{BIT}} or similar. Best example is MySQL here which previously
got a boolean field set to data type {{BIT}} and now returns {{TINYINT(1)}}.
At the same time I removed some PostgreSQL-specific workaround code and used a
proper definition of standard boolean database support inside the core
DBDictionary.
I've also changed some tests to account for that.
I've tested the changes with the following databases:
* MySQL 5.6 (using JDBC driver version 5.1.22 - higher versions produce test
failures for datetime comparison)
* PostgreSQL 9.3 (using JDBC driver version 9.1-901-1.jdbc4)
* Derby 10.8.2.2
* H2 database 1.4.182
* HSQLDB 2.3.2
\\
Other database dictionaries have not been touched so that regressions are very
unlikely.
> Standard SQL boolean mapping impossible
> ---------------------------------------
>
> Key: OPENJPA-2551
> URL: https://issues.apache.org/jira/browse/OPENJPA-2551
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 2.3.0
> Environment: Apache Karaf, OSGi, Apache Derby, MySQL, PostgreSQL
> Reporter: Ancoron Luciferis
> Fix For: 2.4.0
>
> Attachments: OPENJPA-2551-trunk.patch
>
>
> Currently, it is impossible to have a database table column defined as SQL
> standard type {{BOOLEAN}} (defined in SQL-99) automatically working with a
> {{java.lang.Boolean}} or {{boolean}} Java type.
> I am currently testing with:
> # Apache Derby 10.9
> # MySQL 5.6
> # PostgreSQL 9.3
> \\
> All three above databases support the column type definition. However, in the
> case of MySQL, it _magically_ works because the resulting datatype is
> {{TINYINT(1)}}, which is "compatible" with the data type {{bit}} (expected by
> current OpenJPA) - which makes it work by accident.
> For the other two databases, I get the following exception:
> {noformat}
> <openjpa-2.2.0-rUnversioned directory fatal user error>
> org.apache.openjpa.persistence.ArgumentException:
> "org.ancoron.jpa.test.TestEntity.set" declares a column that is not
> compatible with the expected type "bit". Column details:
> Full Name: t_test.C_SET
> Type: unknown(16)
> Size: 1
> Default: null
> Not Null: false
> at
> org.apache.openjpa.jdbc.meta.MappingInfo.mergeColumn(MappingInfo.java:775)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.MappingInfo.createColumns(MappingInfo.java:593)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.ValueMappingInfo.getColumns(ValueMappingInfo.java:178)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerStrategies.map(HandlerStrategies.java:65)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.map(HandlerFieldStrategy.java:82)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:146)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(RuntimeStrategyInstaller.java:82)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.java:496)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:461)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.ClassMapping.resolveNonRelationMappings(ClassMapping.java:895)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping(MappingRepository.java:417)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.meta.MetaDataRepository.preMapping(MetaDataRepository.java:762)[218:org.apache.openjpa:2.2.0]
> at
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:651)[218:org.apache.openjpa:2.2.0]
> ... 81 more
> {noformat}
> \\
> Of course, I have applied a workaround using custom Dictionaries, but the
> main point is that this makes my JPA-only application use
> implementation-specific configuration, which JPA is supposed to avoid.
> Running with EclipseLink instead of OpenJPA works as expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
