writing pojo in database

[P. Ingle]

Hi,

How do I (rather can I) write a pojo in database as object and retrive it back with all the data intact?

pojo is used for holding user specific info which will be used to cofigure the web app according to the set of selections made initially. It has to be updatable.

Can I just write it to database table (DB2 to be specific - may be as blob) and when I retrive it, I cast it to the original pojo type. I am not planning on creating table to map all the attributes of the pojo.

How will this fly in J2EE environment?

Thanks,
P.Ingle

[Scott Johnson]

You could serialize the POJO into a byte array and store that in a blob field, but I wouldn't recommend it.

What if you need to query or update the data in the POJO while it's in the database?

I suggest building a set of tables to store the data from the POJO.

An Object-Relational Mapping tool like Hibernate can make storing and retrieving the data in a POJO fairly painless. (Hibernate has a steep learning curve, but it's well worth the trouble.)

I can think of one situation where storing a POJO as a blob might make sense : sharing session data between web app servers. The data is temporary and would virtually never need to be queried or updated. Outside of that situation, I would go with the ORM tool and a set of tables.

[P. Ingle]

Why is this so frowned upon? Can you point me to any articles that lay out pros and cons of this approach?

Thanks,
P.Ingle

[Stan James]

Serializing can be version dependent. You might store something, upgrade your JVM and find you can't read it back any more. Many of Sun's classes expressly say this in the Javadoc.

Marshalling to some other format - delimited string, XML, etc - and back would be more robust across minor changes like that. Tools like JAXB would hide all the work from you, but they may also be sensitive to structural change. You might store an object, add a field to the class and find you cannot read it back.

I don't know what is safest ... properties files? Key value pairs in a databse?

[Ulf Dittmer]

If you have Beans, you could use the java.beans.XMLEncoder and Decoder classes.

[Scott Johnson]

Storing blobs full of many encoded data fields seems wrong for several reasons.

1. The fields can't be queried or updated using the normal sql tools.
2. Any user of the data has to have your DAO and pojo classes. The data could not be accessed from a non-Java platform.
3. As Stan mentioned, if the class changes you'll be unable to deserialize the object. What happens if your requirements change and you need to add a field? To work around this you'll need be able to detect the object version and use the correct version of the object.
4. You can't use referential integrity to keep the data consistent.
5. You can't join two serialized POJOs in a query.
6. Serialized data fields can't be indexed.

For example, suppose you needed to delete all objects where expired = true. If the expired field is serialized and stored in a blob, you'll need to deserialize every object, check the expired field, and deleted it if necessary. This is a simple delete if the data is stored in a column.

Every application has different requirements so serialization could be acceptable for your situation.

What kind of data are you trying to store? For how long will it be stored? Will it need to be updated or queried? What advantages do you see by using serialization vs storing fields into a table schema?

Regards,
Scott

[P. Ingle]

Originally posted by Scott Johnson:
.......
Every application has different requirements so serialization could be acceptable for your situation.

What kind of data are you trying to store? For how long will it be stored? Will it need to be updated or queried? What advantages do you see by using serialization vs storing fields into a table schema?

Regards,
Scott

The data I want to store represents configuration of a web tool - instead of storing this data into properties file, I am thinking of putting it in database - to make it better managed. There are going to be few default configs which user should be able to pull out, use and may be upgrade. It will be used as a whole - will never be queried on a single item within the pojo. Table will have id, owner (meaning which user can use it), date_modified and the blob field to hold serialized pojo. It will be stored for a long time - if not for ever.

Serialization will make it less schema dependent - having said that, it will make it pojo design dependent according to your comments. Each time the pojo changes, there will have to be a some kind of seperate process to translate this old data into new object and store it back.

Still the issue of JVM remains - which bothers me the most.

Thanks for you comments.