[
https://issues.apache.org/jira/browse/METAMODEL-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kasper Sørensen updated METAMODEL-56:
-------------------------------------
Fix Version/s: (was: 4.1)
4.2
> 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.2
>
>
> 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)
