Simple Image Based Persistence in Squeak
nevin at bountifulbaby.com
Tue Jan 15 17:11:19 UTC 2008
> Image as a database is my way of running my web apps for four years
> already, and I make my living of them, so I can just agree and confirm
> Ramon here!
We have likewise used "image as a database" for bountifulbaby.com for years.
In the beginning we used PostgreSQL, but eventually yanked it. We've
never had a problem with just using the image. However, we have a
couple of other processes in place that help reduce the risk:
1. the production image is saved and a copy is brought over to the
development system for all developmental coding updates. This results
in a production image save about 3 to 5 times per week. The production
image is saved into it's own separate archive area on the development
system(s), so we can revert to the image that existed at virtually any
point in time if we choose to, simply by grabbing any old production
image that we wish to.
2. Several key domain objects use FileStream>>fileOutClass:andObject: to
hierarchically write their contents to disk. This literally spools out
all of the important domain object's data to disk, where they can be
read back in by any other production and/or development image. This
"save" snapshot happens automatically once a day, in the early hours of
the morning. Any image that reads this data back in from disk (via
FileStream>>fileInObjectAndCode) will be restored to the state of the
image at the time of the snapshot.
Consequently, if the production image ever hoses up, we at most risk the
loss of a few hours data. Furthermore, our normal order processing
produces a paper trail from which we can manually update to restore even
that, if we needed to.
But we've never needed to.
The "image as database" approach has been very reliable for us. And a
whole lot easier than any other approach.
More information about the Squeak-dev