Re: [Hsqldb-user] Storing data using the OBJECT data type

[Dale E. <dal...@in...>]

Campbell Boucher-Burnet wrote:
> Here are the details, to the best of my knowlege, based on the current state
> of affairs in 1.7.2 Alpha:
> 
> You can store any Object, including any type of primitive array, in an OTHER
> column, as long as the object (or, if it's a non-primitive array, the base
> type of the array) is java.io.Serializable on the client at the time it is
> stored.  The engine persists and represents OTHER values as byte[] where the
> byte sequence is that obtained by serializing the input Object.  Hence, a
> Server no longer needs to have the Class of all values in OTHER columns on
> its class path.  It no longer materializes OTHER colunn values as Object's
> in the engine's in-memory row buffer.  Instead, it simply loads byte[] into
> memory from persistent storage, wrapping them in org.hsqldb.JavaObject and,
> when requested, sends this to the client, where presumably the Class
> required to deserialize the byte[] to an Object is available in the clients
> class loader context.  One exception is where OTHER column values are used
> in SQL expressions and stored proceedure calls.  In these cases, it is still
> required that the engine itself has been loaded in a class loader context
> that makes the Class of each OTHER column value available to the engine
> internals so that the column values can be materialized as Objects for use
> in expression evaluation and for value passing to stored procedures.
> 
> Finally, there are currently limitations on what you can pass to stored
> procedures.  At the moment, byte,short, float, Byte, Short Float cannot be
> passed, although arrays of byte[], short[], float[], Byte[], Short[] and
> Float[] can be.  This is a limitation of the conversion and SQL data type
> resolution code, steming from the fact that byte,short, Byte, and Short  are
> converted to and represented by Integer internally, while float and Float
> are converted to and represented by Double internally.  In order to get
> around this, we need to introduce special case handling to convert the
> internal representation back to the type accepted by stored procedure
> arguments, before reflectively invoking the java method signature
> corresponding to the stored procedure.  The simple way to get around this
> currently is to always specify int or Integer and double or Double arguments
> for stored procedures.
> 
> Hope that helps,
> Campbell

I'm not sure I understood all of that, but it sounds like I can do it.
The objects I want to store are all of the same class which only includes
int (a little over 150 of them) one String and one BitSet which are both
Serializable.

I am not using stored procedures.  Maybe I am missing out on something. I
don't even know what benefit they might be to me.  Where can I find some
information explaining them.
-- 
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439