[
https://issues.apache.org/jira/browse/DERBY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-651:
--------------------------------
Attachment: derby-651-12-ab-metadata.diff
Attaching derby-651-12-ab-metadata.diff. This patch adjusts JDBC metadata to
account for the fact that UDTs can now be created (see the spec for a
description of the necessary changes). Regression tests passed for me.
Committed at subversion revision 893224.
Changes to metadata queries were needed for
DatabaseMetaData.getTypeInfo()
DatabaseMetaData.getUDTs()
Previous changes already resulted in the correct results for
DatabaseMetaData.getColumns()
ResultSetMetaData.getColumnType()
ResultSetMetaData.getColumnTypeName()
Actually, the wrong results are returned for the ResultSetMetaData methods in
the network client. This is a pre-existing bug and discrepancy with the
embedded behavior. Apparently, when the network client was written, a
deliberate decision was made to coerce object types to LONGVARBINARY. I have
created DERBY-4491 to track this issue.
Touches the following files:
M java/engine/org/apache/derby/impl/jdbc/metadata.properties
M java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java
Changes for DatabaseMetaData.getTypeInfo() and DatabaseMetaData.getUDTs().
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
Added a new test for DatabaseMetaData.getUDTs() and removed it from the test of
vacuous methods.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/CastingTest.java
M
java/testing/org/apache/derbyTesting/functionTests/master/connectionJdbc20.out
Accounted for the new type (JAVA_OBJECT) returned by
DatabaseMetaData.getTypeInfo().
> Re-enable the storing of java objects in the database
> -----------------------------------------------------
>
> Key: DERBY-651
> URL: https://issues.apache.org/jira/browse/DERBY-651
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-651-01-aa-basicCreateDropType.diff,
> derby-651-02-af-udtColumnsRetvalsParams.diff,
> derby-651-03-aa-udttestInstability.diff, derby-651-04-aa-javadoc.diff,
> derby-651-05-ac-dependencyTable.diff, derby-651-06-aa-dropTable.diff,
> derby-651-07-aa-dependencyView.diff, derby-651-08-aa-dependencyRoutines.diff,
> derby-651-09-ac-usagePrivilege.diff, derby-651-10-aa-usageTriggers.diff,
> derby-651-11-aa-dropSchema.diff, derby-651-12-ab-metadata.diff,
> UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html,
> UserDefinedTypes.html
>
>
> Islay Symonette, in an email thread called "Storing Java Objects in a table"
> on October 26, 2005 requests the ability to store java objects in the
> database.
> Old releases of Cloudscape allow users to declare a column's type to be a
> Serializable class. This feature was removed from Derby because the syntax
> was non-standard. However, most of the machinery to support objects
> serialized to columns is still in Derby and is even used in system tables. We
> need to agree on some standard syntax here and re-expose this useful feature.
> Some subset of the ANSI adt syntax, cumbersome as it is, would do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
