Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1488354040.1255105291751.JavaMail.jira@brutus>
Date: Fri, 9 Oct 2009 09:21:31 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-651) Re-enable the storing of java objects
 in the database
In-Reply-To: <1964282168.1130361355487.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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