[
https://issues.apache.org/jira/browse/OPENJPA-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory JEVARDAT updated OPENJPA-2879:
--------------------------------------
Description:
Bug started to appear when I switched to 3.2.0 and I also spotted it in 3.1.2.
Metadada resolution started to fail, with all my XML types columns :(
Debugging pointed me to the merge of columns metadata phase where a call to
isCompatible now returns false instead of true.
Looking at the code the add of the case Types.SQLXML at line 788 is causing the
isCompatible to return false for any of my XML columns. Indeed, previously the
SQLXML columns where not catched in this case and were relying on the default
case simply testing equality of the columns.
I'am wondering in general why the test of the 2 types equality is not done
before.
As a quick fix I just added a case testing if the SQLXML is equals to itself
like for instance
{code:java}
case Types.SQLXML: // All XML Types
case 2007: // Oracle-defined opaque type code for XMLType treated the same way
switch (type) {
case Types.CHAR:
case Types.LONGVARCHAR:
case Types.VARCHAR:
case Types.CLOB:
case Types.BLOB:
case Types.SQLXML:
return true;
default:
return false;
}
{code}
Maybe a proper fix is simply to revert the catch of Types.SQLXML, but I'am not
sure I understand all the hiddent details and assumptions here ... I think it
is strange than test equality is not tested right at the top of the method...
This bug is quite blocking in my case openjpa fails metadata initialisation
Cheers
Gregory
was:
Bug started to appear when I switched to 3.2.0 and I also spotted it in 3.1.2.
Metadada resolution started to fail, with all my XML types columns :(
Debugging pointed me to the merge of columns metadata phase where a call to
isCompatible now returns false instead of true.
Looking at the code the add of the case Types.SQLXML at line 788 is causing the
isCompatible to return false for any of my XML columns.
I'am wondering in general why the test of the 2 types equality is not done
before.
As a quick fix I just added a case testing if the SQLXML is equals to itself
like for instance
{code:java}
case Types.SQLXML: // All XML Types
case 2007: // Oracle-defined opaque type code for XMLType treated the same way
switch (type) {
case Types.CHAR:
case Types.LONGVARCHAR:
case Types.VARCHAR:
case Types.CLOB:
case Types.BLOB:
case Types.SQLXML:
return true;
default:
return false;
}
{code}
But again I think it is strange than test equality is not tested first in is
compatible...
This bug is quite blocking in my case openjpa fails metadata initialisation
Cheers
Gregory
> Regression in Column.isCompatible
> ---------------------------------
>
> Key: OPENJPA-2879
> URL: https://issues.apache.org/jira/browse/OPENJPA-2879
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 3.1.2, 3.2.0
> Reporter: Gregory JEVARDAT
> Priority: Major
>
> Bug started to appear when I switched to 3.2.0 and I also spotted it in 3.1.2.
> Metadada resolution started to fail, with all my XML types columns :(
> Debugging pointed me to the merge of columns metadata phase where a call to
> isCompatible now returns false instead of true.
> Looking at the code the add of the case Types.SQLXML at line 788 is causing
> the isCompatible to return false for any of my XML columns. Indeed,
> previously the SQLXML columns where not catched in this case and were relying
> on the default case simply testing equality of the columns.
> I'am wondering in general why the test of the 2 types equality is not done
> before.
> As a quick fix I just added a case testing if the SQLXML is equals to itself
> like for instance
> {code:java}
> case Types.SQLXML: // All XML Types
> case 2007: // Oracle-defined opaque type code for XMLType treated the same
> way
> switch (type) {
> case Types.CHAR:
> case Types.LONGVARCHAR:
> case Types.VARCHAR:
> case Types.CLOB:
> case Types.BLOB:
> case Types.SQLXML:
> return true;
> default:
> return false;
> }
> {code}
>
> Maybe a proper fix is simply to revert the catch of Types.SQLXML, but I'am
> not sure I understand all the hiddent details and assumptions here ... I
> think it is strange than test equality is not tested right at the top of the
> method...
> This bug is quite blocking in my case openjpa fails metadata initialisation
> Cheers
> Gregory
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
