Hi,
what should be the best way to store java objects serialised into a
db ?
standard JDK serialisation ?
xstream xml serialisation ?
or ???
and what about this things when desirialize the stored objects? :
1. only the serialnumber of class changes
2. only a field was added
3. only a field was removed
4. only the logic was changed
5. : 2 and 4
6. : 2 and 3
7. 1,2,3,4
or what other thinks are problematic ?
thanks
mfg Matthias
Lew - 22 Jun 2007 12:53 GMT
> what should be the best way to store java [sic] objects serialised into a
> db ?
[quoted text clipped - 3 lines]
>
> or ???
JDBC. What good would Java-style serialization do in a database? How would
you store, say, a really large object tree in the db? What good is a db if
you've hidden all the structure from it?
With JDBC you map fields in objects to corresponding columns in table rows.
This yields a structured representation of the data in the db.

Signature
Lew
Tris Orendorff - 22 Jun 2007 18:45 GMT
> Hi,
>
[quoted text clipped - 5 lines]
>
> or ???
You should not store serialized java objects into blobs in a db. You should store them into tables using JDBC
and the normal field types: integer, date, etc. If you do keep them in blobs then searching and sorting on
values in the blob will be too slow with more than 1000 (or so) records.

Signature
Tris Orendorff
[Q: What kind of modem did Jimi Hendrix use?
A: A purple Hayes.]
Roedy Green - 24 Jun 2007 10:14 GMT
>standard JDK serialisation ?
>xstream xml serialisation ?
standard serialisation is much more compact. The problem with all
serialisations is they fail as soon as the format of the object
changes. If there is any possibility the format of the object might
change in future, use a DataOutputStream to serialised it.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com