[
https://issues.apache.org/jira/browse/DERBY-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573464#comment-13573464
]
Knut Anders Hatlen commented on DERBY-6000:
-------------------------------------------
derby-6000-06-aa-DatabaseMetaData.diff added a DatabaseMetaData method named
getMaxLogicalLOBSize(). In my copy of OpenJDK, it is actually called
getMaxLogicalLobSize(), so I guess it needs to be renamed.
The javadoc in the specification says it returns "the maximum number of bytes
this database allows for the logical size for a LOB." For a CLOB, I'd say the
number of bytes would be the physical size, not the logical size, so I'm not
sure exactly what we should return here. The patch assumes UTF-16 with two
bytes per character, which matches the in-memory representation. On disk, CLOBs
are stored in UTF-8, which may have more than two bytes per character.
Right now we return 4294967294. But we don't allow BLOBs to be more than
2147483647 bytes. Could this trick applications into attempting to create
tables with BLOB columns whose declared size is greater than the maximum length?
4294967294 is the maximum number of bytes we could possibly accept (assuming
CLOBs are UTF-16 encoded) in a LOB column, but we don't always accept that many
bytes.
2147483647 is the maximum number of bytes we know we can always accept in a LOB
column.
Returning the latter number would have been more in line with my expectation of
how that method should work, I think. But I agree that the implemented
behaviour is a just as reasonable interpretation of the words in the spec. I
suppose the text was written for databases that store CLOBs as BLOBs
internally, and whose maximum CLOB size is limited by the maximum number of
bytes a BLOB can hold.
> Implement support for JDBC 4.2
> ------------------------------
>
> Key: DERBY-6000
> URL: https://issues.apache.org/jira/browse/DERBY-6000
> Project: Derby
> Issue Type: Improvement
> Components: JDBC
> Reporter: Rick Hillegas
> Attachments: derby-6000-01-aa-executeLargeUpdateEmbedded.diff,
> derby-6000-02-ad-executeLargeUpdateClient.diff,
> derby-6000-03-aa-executeLargeBatch.diff,
> derby-6000-04-aa-setLargeMaxRows.diff,
> derby-6000-05-aa-executeLargeUpdatePS.diff,
> derby-6000-06-aa-DatabaseMetaData.diff,
> derby-6000-07-ab-batchUpdateException.diff,
> derby-6000-08-aa-batchUpdateExceptionConstructor.diff, JDBC_4.2_Changes.html
>
>
> Open JDK 8 will include maintenance rev 4.2 of JDBC. The public discussion of
> JDBC 4.2 will take place here: http://openjdk.java.net/jeps/170. We will want
> to build Derby support for JDBC 4.2 after a public spec appears. At this
> time, it is unclear what Derby release will carry this support.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
