[jira] [Resolved] (METAMODEL-56) Make JDBC metadata about CLOB/BLOBs consistent with "convert LOBs" system property

["Kasper Sørensen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/METAMODEL-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kasper Sørensen resolved METAMODEL-56.
--------------------------------------

       Resolution: Fixed
    Fix Version/s: 4.1

> Make JDBC metadata about CLOB/BLOBs consistent with "convert LOBs" system property
> ----------------------------------------------------------------------------------
>
>                 Key: METAMODEL-56
>                 URL: https://issues.apache.org/jira/browse/METAMODEL-56
>             Project: Metamodel
>          Issue Type: Improvement
>            Reporter: Kasper Sørensen
>            Assignee: Kasper Sørensen
>             Fix For: 4.1
>
>
> Now that we've fixed METAMODEL-54 we can finally adress this issue (raised on mailing list in subject "Concern regarding ColumnType.getJavaEquivalentClass()"):
> In our ColumnType enum we have the method getJavaEquivalentClass() which is used to tell which java type to expect when querying a particular column. For instance, of I query a VARCHAR column, I can expect a java.lang.String value.
> Now the trouble is that in our JDBC module we have a system property which allows for eager loading of BLOBs and CLOBs so that they are automatically read into byte-arrays and Strings respectively. This is a great utility because otherwise the user has to do a lot of tedious work with inputstreams etc which in most cases isn't particularly useful - in most cases you just want the byte[ ] or String.
> Now the trouble is that if you turn that system property on, you get Strings or byte-arrays but the column type is still CLOB/BLOB and that means that the "expected equivalent Java class" is still java.sql.Clob or java.sql.Blob! If you build your code to expect that, then it will eventually break because you get a String or a byte-array instead.



--
This message was sent by Atlassian JIRA
(v6.2#6252)