These accessors are notoriously vendor specific. What we are doing is, for instances which are java.io.Serializable, storing these as a byte object serialization in a LONGVARBINARY. This is pretty much the same thing as calling setObject/getObject for a database that knows how to serialize an arbitrary Java object, but has the advantage that it works for JDBC drivers which don't support this behavior as well.

Basically, setObject and getObject are calls on a PreparedStatement and ResultSet, respectively, which allow the user to use java.lang.Objects in the SQL statement. The JDBC documentation contains the following statement: "Note that this method may be used to pass database specific abstract data types, by using a Driver specific Java type." Thus, some databases may support Java types which go beyond the primitive SQL data types. In particular, some databases allow any serialized Java object to be put into or retrieved.

We do not rely on this driver-specific behavior, but instead use Java serialization to convert the Java object to/from a byte array, and use (LONG)VARBINARY type to store the data. This is more portable, but may be slower than using setObject/getObject directly. (Actually, we doubt it is slower, since presumably most JDBC drivers simply do the serialization themselves under the covers.)