Prevayler

Bernard replies to my reply:

Me: My thoughts were that it is easier to transform bare data as it is less to transform. You take the old data and insert it into the new code, which is all you need because you don’t want the old implementation anyway.

Bernard: I guess you are somehow comparing apples and oranges. If you want to compare data storage then instead of storing Java objects with data and business logic, just store some objects having data only. Sure, if you store objects with only data you are quite close to the tabular data model. But remember, I only want to be able to “offer” it for OLAP purposes and for upgrades, if then.

Bernard commented on my thoughts on schema evolution.

I do not see why schema evolution is harder to handle in Prevayler than it is with a relational database. Changing relations is always a problem whatever the storage strategy you use.

Hmm, let’s see. Maybe I was very using traditional thinking. My thoughts were that it is easier to transform bare data as it is less to transform. You take the old data and insert it into the new code, which is all you need because you don’t want the old implementation anyway.

We’re right now trying out Prevayler as a persistence layer for our products. It is basically the coolest think I’ve seen since I became an OO-afficionado. I did start out with Smalltalk, and it sort of set the tone for what I believe in.

I need to check out if Jon has mentioned this on his blog. Nope, he hasn’t so I’ll be first then.

Here we go: What Prevayler basically does is store your object graph in memory, recording every transaction as a serialized Command. Every 24 hrs a snapshot of the full object graph is written to disk and the log is cleared. Crash recovery is performed by taking the latest snapshot and redo all the commands that is deserialized from the log.

Jon and I had a pretty heated discussion today over serialized objects. The background is as follows:

Using Prevayler, you will have a file on your disk with your serialized object graph. This stores the state of your application, but, very important, also the implementation of that state. When deserializing the object graph, you do not retrieve properties that are set on “new” objects, you are retrieving the object itself. Like, duh.