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 Fri, 09 Oct 2009 16:21:31 GMT

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

Rick Hillegas updated DERBY-651:
--------------------------------

    Attachment: UserDefinedTypes.html

Thanks for the great feedback, Dag. I am attaching a second rev of the spec, which addresses
many of your comments:

    *  Clarify that these are structured, not distinct types.
    * Clarify that instance methods are not covered by this first increment.
    * Clarify that declared public fields can be selected.
    * Clarify that UDT names are schema-qualified names.
    * Clarify authorization language.
    * Clarify the importance of defensive code to handle client/server version mismatches.
    * Fix links to java.sql.Types.JAVA_OBJECT javadoc.
    * Cite the JDBC spec to explain why java.sql.Types.JAVA_OBJECT is the value of DatabaseMetaData.getColumns().DATA_TYPE
for UDT columns.
    * Clarify that by definition, UDTs are nullable.
    * Clarify that SYSALIASES.ALIAS holds the UDT's name.
    * Clarify that SYSCOLUMNS.REFERENCEID and SYSPERMS.OBJECTID continue to be UUIDs.
    * Clarify that down-rev clients can access UDTs after hard upgrade.

In the meantime, I have been toying with the idea of simplifying the CREATE TYPE syntax. I
would like to get feedback on this proposal before addressing your other comments, many of
which hinge on the syntax of the CREATE TYPE statement.

I believe that the following extension would be compatible with the SQL Standard and would
greatly simplify the task of the type designer in mapping Java to SQL types. We could extend
the standard syntax with a new <user defined type option> (see part 2 of the standard,
section 11.42 <user-defined type definition>):

STYLE DERBY

Here's the simplified Derby syntax for binding a SQL type to a Java type:

CREATE TYPE [ schemaName . ] typeName
EXTERNAL NAME singleQuotedJavaClassName
LANGUAGE JAVA
STYLE DERBY

With this syntax, you would not need to declare public attributes, methods, and constructors.
Derby would automatically recognize them. Here's how simple the declaration of the example
Price type would look using this syntax:

CREATE TYPE price
EXTERNAL NAME 'com.acme.types.Price'
LANGUAGE JAVA
STYLE DERBY

This would eliminate the need for an ALTER TYPE statement and so dodge the odd limitation
in part 13, section 9.6 <alter type statement>. For the first increment, Derby would
just recognize public fields of the bound class. In later increments, we would add support
for public methods and constructors.

What do you think? 




> 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
>         Attachments: 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, cumbersom 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