db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-651) Re-enable the storing of java objects in the database
Date Tue, 22 Dec 2009 16:38:29 GMT

     [ 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.


Mime
View raw message