Avi wrote:
> Depending on the protocol, you often bring in clusters of 
> objects at once from the server (I think Magma calls this the 
> "read strategy", and you can modify it).  So these can all be 
> becomeForwarded at once.

Yes.

> The easiest way around #becomeForward: is to simply keep the 
> proxy around and have it forward all its messages to the real 
> object.  When I was playing with a GOODS client I actually 
> had #becomeForward: in the other direction, in that whenever 
> you did a commit it would replace all of the new objects with 
> proxies that pointed to them.  The proxy was a sort of 
> "object manager" that tracked which objects were touched by 
> the transaction, had methods for lock management, and so on.

In the OODB that I'm working on, I'm trying to avoid any use of
#doesNotUnderstand: and identity trickery.  In the past I've tried to
make things as transparent as possible, but I'm starting to believe that
strategy is not as useful as it might seem.  While I haven't come to any
firm conclusions on the issue, my reasoning is this: in my experience,
even when things are very transparent, you really still need to
understand how things are working below the covers in order to be
effective, and trying to make things automatic actually works against
that understanding.  Also, doing a lot of #dnu and identity tricks make
things difficult to debug.

So...given my current thinking on this issue, I'm taking an approach
that not only keeps the proxies around, but the proxies don't even
forward messages with #dnu.  Actually, I guess that means they're not
really proxies.

The way it works is the OODB only creates PIDs (persistent ids) for
clusters of objects.  These clusters are accessed through instances of
PdbObjectReference (which contains the PID, and some cache related
info).  You send the message #deref to access a cluster behind a
PdbObjectReference and you only hold the PdbObjectReference in your
domain...so, for example, if you have a Person that holds an Address,
you have a decision to make...do you store the Address with the Person
in a single cluster, or is address going to be the root of its own
cluster.  If you choose to make Address a part of the Person cluster,
you design your instvars and accessing methods as normal...if however,
you want it to be an independent cluster, you would write your address
accessing methods something like:

----
Person>>address

	^addressRef deref

----
Person>>addressRef: anAddressRef

	addressRef := anAddressRef

----
Person>>addressRef

	^addressRef
----

You might also choose to have an address setter that will assign a
reference:

----
Person>>address: anAddress

	addressRef := anAddress ref
----

...but this only works if you have a back pointer (or dictionary) where
you can lookup or assign a PdbObjectReference.  It also depends on
having some contextual information about which PdbPersistentMemory is
currently in use.

Then, when you save a Person, the cluster will be clamped at the
addressRef (the serialization stops when instances of PdbObjectReference
are encountered)...if a related PdbObjectReference has never been
stored, then the persistence will cascade, making sure that all
referenced objects get stored.

I only do a few transparent like things in this scheme...for
example...PdbObjectReference overrides #inspect and #explore such that
it actually inspects or explores its target.  Also, #printOn: writes
'-->>' followed by the printOn: of the target (or '(object on disk)' if
it's not cached)...this gives you a visual clue in the inspectors that
you're holding a PdbObjectReference, but it when you double click to
inspect an instvar holding a reference, you actually inspect the target
of the reference (you can use #basicInspect if you need to actually get
the PdbObjectReference).  This seems to be a nice balance because it
makes it easy to dive around a domain, while not making things too
transparent.

> Actually, with the recent interest in object databases I'm 
> thinking about reviving that GOODS client... if anyone would 
> be really interested in it let me know.

The more OODBs the merrier.

- Stephen