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