Avi Bryant <avi at beta4.com> said:
>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?
>
AFAIK, anything without an OID gets included by value. ZODB persistence is
based on the Python pickle library
(http://www.python.org/doc/current/lib/module-pickle.html), the documentation
on that is fairly extensive. 

>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? 

Given the fact that there is not much difference in Smalltalk between a
'persistent' object and a non-persistent object (except for the indication
that you want to persist an object by reference or by value), there are two
options:
- Automatically make persistent anything that's registered with a transaction;
- Throw an exception when a non-persistent object (however it's marked
  persistent) is registered with a transaction.
I'm in favour of the second solution, it's bound to catch programmer errors
more quickly than the first solution which risks that an object you meant as a
reference object is stored twice.

>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?
>
That's a matter of taste and philosophy. ZODB intercepts instance variable
access through the ExtensionClass mechanism. I work with OmniBase under
VisualWorks which needs 'self markDirty' all over the place. Both have the
notion of a thread-local transaction where the object is automatically
registered when it's marked dirty, and both require the programmer to
explicitely close the transaction - I think both items make a lot of
sense. As for dirtying an object, I like the ZODB approach better, and
I think that it should be very doable in Smalltalk.  However, I wouldn't
object to the 'self changed' solution, because it doesn't really get in the
way.

>I ask all of this because I've been thinking about similar designs myself
>without coming up with satisfactory answers. 

That's because orthogonal persistence is a very hard thing. Having worked with
O/R mapping variations and OO databases, I must say that I greatly prefer the
latter. Basically, I don't see any problems solved by an O/R mapping layer
(now talking from the 'blank sheet of paper' perspective - you don't have an
existing RDBMS that you need to interface with), only problems introduced.

-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B