1.0

Table Of Contents
Chapter 28
Programming User-Defined Types
SQLFire enables you to create user-dened types. A user-dened type is a serializable Java class whose instances are
stored in columns.
Note: This topic was adapted from the Apache Derby documentation source, and is subject to the Apache
license:
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
User-dened functions can be dened on columns of user-dened types. You can also use these types can as argument
types for stored procedures, as described in Using Data-Aware Stored Procedures on page 143.
Note: You cannot register a custom .NET type as a user-dened type in SQLFire.
The class of a user-dened type must implement the java.io.Serializable interface, and it must be declared to SQLFire
by means of a CREATE TYPE statement. You can install user-dened type classes to SQLFire as part of a JAR le
installation, as described in Storing and Loading JAR Files in SQLFire on page 111.
The key to designing a good user-dened type is to remember that data evolves over time, just like code. A good
user-dened type has version information built into it. This allows the user-dened data to upgrade itself as the
application changes. For this reason, it is a good idea for a user-dened type to implement java.io.Externalizable and
not just java.io.Serializable. Although the SQL standard allows a Java class to implement only java.io.Serializable,
this is bad practice for the following reasons:
Recompilation - If the second version of your application is compiled on a different platform from the rst version,
then your serialized objects may fail to deserialize. This problem and a possible workaround are discussed in the
"Version Control" section near the end of this Serialization Primer and in the last paragraph of the header comment
for java.io.Serializable.
157