cg at cdegroot.com (Cees de Groot) wrote:
> I was just explaining the ZODB design to a colleague, 

Thank you for explaining it to me, also.  ZODB has sounded interesting
for a long time but my occasional quick glances at never led to
understanding it.  (If you do get a chance to review its documentation,
please feel free to repeat and expand your explanation of how it works.)

> and it struck me that 
> this might be a very useful persistence engine design for Squeak. It's simple, 

I have been using a combination of Dolphin Smalltalk for the clients and
Python/Metakit as a database server.  I've been very pleased with
Metakit and my Python/Metakit server "just works" for perhaps months at
a time before I need to add or change my Python code.  However, when I
do, there is a certain stress on me in "shifting gears" from Smalltalk
back to Python/Metakit as it takes me a long time to get re-oriented. 
(In hindsight, I wish I had done many things different, but one thing
would have been to pass Python code from the client directly to the
Python server to be interpreted, so even when writing Python code I
would stay in Smalltalk.)

That (the desire to stay in Smalltalk all the time), plus the recent
persistence discussions along the lines of "RAM is cheap; let's use it",
plus the fact that this application's data size is fairly small
(typically 150,000 to 250,000 business objects occupying perhaps 8 to 16
MB when represented in text files -- I don't quite know what that would
translate to in terms of Smalltalk memory usage), have led me to
consider switching the server over to Squeak and keeping all the objects
in RAM all the time.  I thought I'd want to write a transaction log and
then save out the objects to disk at the end of the day (or whenever). 
If all went well, the next time the server started up, it would reload
the objects from the saved out version, otherwise, it would reload the
previous good version and replay the log.

If I followed your ZODB explanation, its approach would be similar to
that in my previous paragraph except it is only the dictionary of
oid-to-starting-address-in-log-file that is kept in RAM all the time and
rewritten out and reloaded.

> The structure (now I'm going to tread dangerous territory here - this is from 
> the back of my head, I really should refresh my knowledge from the docs) is 
> basically: magic, transaction header, object, object, object, ..., transaction 
> header, object, object, object, ... etcetera. Objects have backpointers to 

What would we write in the log file if we did it in Squeak?  Since some
of my business objects point to other business objects, etc. etc., how
complicated must the proxying of objects be?  I am doing that now in the
client and one of the appeals of keeping all the objects in RAM all the
time was the possibility of eliminating the need to deal with proxies
altogether, or at least restrict it to server start-up time.  Any
thoughts or suggestions in this area?  (Of course, at first, even though
either all the objects or just their oid dictionary would be in RAM on
the new Squeak server, the clients would continue as if it were
Python/Metakit serving them, but later I would hope to use lighter
clients with all the work done on the Squeak server.)

> all performs reasonably well makes it an ideal candidate for a built-in 
> persistence mechanism for Squeak, methinks.
 
> Would that sound like something useful for Squeak? 

I certainly think so.

> It has its limitations, for 
> sure, but it seems like the simplest way to get a solid persistence engine 
> into Squeak, which is a Good Thing I think. It's also a project I'd like to 
> tackle...

I'll look forward to it.


-- Frank
If we had realized how difficult it would be, the Romans would
not have begun building the pyramids nor would I have begun
studying history.