On Thu, 31 Jan 2002, Cees de Groot wrote:
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 parent versions, transactions too - this mean you can 'timetravel' to older transactions or older object versions (guess how trivial it is to build a Wiki on top of that...).
A few questions -
Does anything without an oid get serialized in full to the transaction log, as part of its parent object? How does it recover the oids from the objects when writing to disk - does it keep a reverse map object->oid? Or does every business object have to have an oid field?
Which brings me to - what can be used in business objects? In Squeak, will standard collections be usable, or will you have to use an ODBDictionary, ODBOrderedCollection, etc, that have oids, and can associate themselves with transactions? And how do most objects (that don't have an easy at:put: protocol) know they've been modified? Compiler hacks like kats uses? VM hacks? Or do your business objects have to send "self changed" all the time?
I ask all of this because I've been thinking about similar designs myself without coming up with satisfactory answers. What I've been looking at instead, recently, is generalizing my hacked together little O/R mapping framework (sort of a GLORP-lite) so that it will work with simple in-memory tables as well as RDBs. Once you map an object structure down to simple relational tables (or arrays of dictionaries of strings, which is what a relational table looks like to my framework), transactions become very easy to serialize. Of course, the disadvantage is that you're constrained by the O/R model and have to have all of this metadata about relationships, etc. One upside is that you can freely mix your "object" (in-memory) DB and any relational DBs you need to use, in terms of having relationships between them, since they all use the same model. The other is that all of the DB-related stuff is totally external to your business objects, rather than forcing them to inherit from anything in particular (although you still have the "self changed" problem to some degree).
I don't particularly like this approach, so if you manage to get a ZODB lookalike working, I'll be very pleased. I'm also happy to help out if you need it.
Cheers, Avi