You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Ancoron Luciferis (JIRA)" <ji...@apache.org> on 2014/12/10 16:49:12 UTC

[jira] [Created] (OPENJPA-2551) Standard SQL boolean mapping impossible

Ancoron Luciferis created OPENJPA-2551:
------------------------------------------

             Summary: 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


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)