Hi Derek!

Derek Brans <brans at nerdonawire.com> wrote:
> Hi Goran,
> 
> I used your code almost word for word.  It seems to work like a charm.  AND
> your code keeps versions.  How much easier could persistence be?  What
> drawbacks have you encountered?

Well, not many. Off the top of my head:

1. You can only "snapshoot" the complete model instead of parts of it
(like Magma can using transactions). But this is often ok, for example
in simple applications or "documentish" apps. In two of my apps I have
been forced to "split" my models in order to be able to save two
different parts in ImageSegments of their own. I just cut the normal
object reference and turned it into an integer id instead in combination
with a Dictionary. Sure, ugly - but if you can get away with just a few
different parts then it's still ok. My apps saved personal accounts
separated from the documents they contained.

2. ImageSegments are either *completely in RAM* or *not*. This means a
single ImageSegment can't get too large. But again - for many apps the
amount of available RAM today is more than enough.
 
In short - using ImageSegments like this is a solid way of
loading/unloading parts of the object memory. Sure, saving forces more
or less a GC so it can take a little bit of time - but it's still very
fast.

When this mechanism is not enough Magma is probably the logical next
step - more or less the same simplicity but with transactions, scalable
collections, networking, locks, faulting policies and all those other
goodies that you may want when moving forward. And it would be very easy
to change an app into using Magma since both techniques are very
non-intrusive (compared to RDB solutions which tend to crawl all over
the place).

But Magma wasn't there when I started using ImageSegments! :-)

regards, Göran