[Seaside] Re: Seaside and GOODS

Avi Bryant avi.bryant at gmail.com
Fri Mar 18 12:58:47 CET 2005

On Thu, 17 Mar 2005 23:05:11 -0500, Daniel Salama <dsalama at user.net> wrote:

> Is there any further documentation on your BTree package? I've been
> trying to follow the source, but the "lack" of comments (please
> understand I'm still learning Smalltalk) makes it more difficult. For
> example, your suggestion of BTree order: 20... what does it mean? I
> don't even find a method order: in the source other than simply source
> which returns the number of elements of 'root'

"BTree order: 20" is an expression which sends the message #order: to
the class BTree.  That means if you're looking for the method you need
to look on the class side (click the "class" button on the browser
where it says "instance | ? | class").

Or select #order: and hit alt-m to browse implementors of that
selector - there aren't many.

There's no documentation, but the protocol is pretty standard for
mapped collections in Smalltalk - #at:, #at:put:, #at:ifAbsent:,
#removeKey:, #do:, #keysAndValuesDo: all work similiarly to
Dictionary.  The only difference is that keys need to be sortable (ie
need to implement #<=).

> Then again, how do you create indices? Is this something GOODS related?
> I couldn't find documentation about it. I must be missing something
> because others I've talked to about GOODS have mentioned it to me as
> well.

By "index" I just mean "some keyed collection you're using to index a
property of your objects".  A BTree would be a common class to use as
an index.

> Is stateAt: a user-defined method of my "BTree" descendant class?

I wouldn't recommend subclassing BTree - normally it's better to have
a separate class with an instance of a collection than a subclass of a
collection.  But yes #stateAt: is something I made up that you'd have
to implement yourself.  I was assuming some custom root class that had
instance variables for the various indices you needed, and methods for
accessing them.  You could also just use a dictionary at the root and
have indices at various keys, in which case that would look something

(db root at: 'statesByAbbreviation') at: 'FL'

but I recommend encapsulating things better than that.

> Understood. However, there may be cases where I do accept user input in
> free-form text (such as when asking for parameters to generate a
> report). What would you suggest then? Traverse the "look-up objects"
> (e.g. BTree lookup by key, for example), fetch the object and use the
> entire object as reference?


> > Generally, I recommend making the collection side of this the public
> > interface, and the backlink private (#setState: vs. #state:) and never
> > sent directly.  Or the other way around, but be consistent about which
> > you use.
> >
> This really confused me. Are you referring to making State>>addCity:
> public instead of State>>city: or State>>cities:?

Well, yes.  Buty also instead of City>>state:.  To maintain data
integrity, you have to ensure that any time you add a city to a
state's #cities, it gets updated to have #state point to that state,
and vice versa.  So either #addCity: is going to have to send #state:,
or #state: is going to have to send #addCity:.  The simplest thing is
to have whichever one of those *doesn't* call the other be private.

> > The main reason at this point I would opt not to use GOODS for a
> > particular project would be performance concerns - having to do
> > everything over the network, combined with a lack of server-side
> > querying, can be a real problem for some applications.  Local-disk
> > solutions like OmniBase have a real advantage here.  I do think,
> > however, that it would be possible to do some aggressive caching in
> > GOODS to improve the situation - I just haven't had time to work on
> > that yet.
> This may be indeed a negative point. I don't know if this is common to
> most OODB implementations or restricted to a smaller subset, in which
> GOODS happens to fall in.

The latter.  Many OODBMS either allow server-side querying (for
example, GemStone has a Smalltalk VM on the server so that you can run
arbitrary Smalltalk queries), or don't have a client/server
distinction at all (like OmniBase which reads and writes directly to
the filesystem from your Smalltalk image).   GOODS has neither, which
makes it especially important to use good data structures in your
GOODS applications.


More information about the Seaside mailing list