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

Reply via email to