[OPENJPA-2879] Regression in Column.isCompatible

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.1.2, 3.2.0
• Component/s: jdbc
• Assignee: Unassigned
• Reporter: Gregory JEVARDAT
• Created: 26/Jul/21 07:14
• Updated: 05/Jun/23 09:47

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

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;
 }

 
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

 

 

Issue Links

• is broken by: OPENJPA-2761 problem inserting more than 4000 charcters in oracle XMLTYPE column
• links to: GitHub Pull Request #110