On Sun, 2003-06-29 at 19:06, Derek Brans wrote:
> I want to use arbitrary persistent objects as btree keys.  Could this
> be accomplished by using the object's ObjectID in the database?  
>
I would not recommend this - first, there are no guarantees that object
id's don't change (I'm not sure they stay constant over a GC, but in any
case, no-one guaranteed it so assume the guarantee to be absent ;-)),
second a Btree usually implies ordering of keys, and oid's aren't
ordered. However, I cannot give you a specific example of when oid's
*do* change, so you may want to try nevertheless.

If you do want to use them, they're 5 bytes long - a byte for the
container ID and an unsigned long for the offset in the object index
file.

> If so, what would you recommend using as the key (is ObjectID>>hash
> unique)?
>
A hash is never guaranteed to be unique. If two objects are the same,
the hashes must be the same, but that doesn't hold the other way around.

> a) Have all sub-object edits go through the cluster's root object
> b) Have the sub-object somehow notify the cluster's root object that
> it is dirty.
>
It depends a bit on how closely coupled the various objects are. For
tightly coupled objects, it might be appropriate to have the root object
offer a facade for all the sub objects; for general cases, I'd use event
notification.

> I can't start any new transactions on my database because I get the
> error: "Maximum number of clients reached" in
> ODBClientManager>>newClient.
> I think OCBCientTable is having difficulty locking the client ID
> table.  Could this be a bug?
>  
A client is a connection to the database, created (AFAIK) when you open
the database, not when you start a new transaction on a database. Do you
have a code snippet to reproduce this?

>  
> Question 4 - BTreeIndexDictionary
>  
> The documentation says that this class maps keys to sets of values (ie
> keys need not be unique).  However #at: only returns one value
> holder.  I don't get it.
>  
#at: probably returns the first match, which would be consistent with
#at:'s usual behavior (return only a single object). You probably want
to look at #forKeysStartingWith:do: (and probably other methods) if you
want to fetch a whole bunch of things.



-- 
Disclaimer: all Dutchmen are liars