In the Java world, varchar should support UNICODE characters, not 8-bit
bytes.
Yes, I know some data bases do not store UNICODE, but some (Oracle,
InstantDB etc) do. The other problem with character, is character encoding,
when/if the encoding of the application does not match the native character
encoding of the table, a translation is performed, and the results are not
always reversible.
The correct type used to store serialized data is byte, or varbyte, or even
blob.
Remember, Java characters are unsigned sixteen bit numbers not eight bit
data elements (called char by 'C', 'C++' and many databases).
----- Original Message -----
From: Krishna R. Baddam <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 7:25 PM
Subject: RE: JDBC-Session store
> Blob is a bad idea. Serialize the objects and store them as varchar. We
> implemented a home grown session store and the varchar route works lot
> better. I believe IBM's WebSphere session store also uses varchars.
>
> Krishna
>
> -----Original Message-----
> From: Bip Thelin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 2:13 AM
> To: [EMAIL PROTECTED]
> Subject: JDBC-Session store
>
>
> I've been looking at the FileStore implementation and you(Kief/Craig)
> basically
> store a java object in the textfile, using the same approach with a DB
> usually(?!)
> involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want
to
> store
> the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of
> reluctant
> to save objects in to a RDBMS and sort or "overriding" the native formats.
>
> Have anyone got any ideas on how to solve this in a good way? Preferably
so
> it would
> work with JDBC < 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go
> ahead and
> implement it as either a blob or a STRUCT whichever works out best.
>
> Thanks, Bip
>
>
