You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Romain Manni-Bucau (Jira)" <ji...@apache.org> on 2021/08/02 12:13:00 UTC

[jira] [Commented] (OPENJPA-2879) Regression in Column.isCompatible

    [ https://issues.apache.org/jira/browse/OPENJPA-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391545#comment-17391545 ] 

Romain Manni-Bucau commented on OPENJPA-2879:
---------------------------------------------

Guess the default shouldn't be a return false/true but a return type == getType(), can you try this "fix"?

> 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)