[Seaside] Re: Seaside and GOODS

[Daniel Salama]

On Mar 17, 2005, at 9:12 AM, Avi Bryant wrote:

> Right; the standard collection classes assume that the entire
> collection is resident in memory, and optimize accordingly.  BTree and
> TSTree assume that the collection is mostly resident on some slower
> media (like disk or over the network) and so try to minimize how much
> of it needs to be loaded in for any given request.
>
> A 5-digit zip code would probably want to be stored as a SmallInteger
> key in a high-order BTree (IIRC, something like "BTree order: 20").
>

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'

> I would expect this to look something like
>
> (self root stateAt: 'FL') cities asSortedCollection gather: [:ea | ea
> allZipCodes]
>
> That is, the root would have an index of states; the State object
> would have a list of its cities; the City would have a list of its zip
> codes.  After the initial lookup of 'FL' it's all direct pointer
> references.
>

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. Is stateAt: a user-defined method of my "BTree" descendant class?

> No. :)  Don't look stuff up by keys except when the keys are user
> input (like 'FL' above, and even there, ideally they picked it from a
> list which in Seaside means you should have a direct reference to the
> object anyway).  The equivalent of a foreign key column is simply a
> pointer reference (in an instance variable).  If you need to go in the
> other (to-many) direction, store a collection.  You'll sometimes only
> need one or the other, and sometimes need both - in which case you
> have to be careful to maintain the invariants:
>
> State>>addCity: aCity
>     aCity setState: self.
>    ^ cities add: aCity
>

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

> There are very few situations where I will use an RDBMS by choice.
> Unless there's legacy data to deal with, or the client specifically
> requests it, I would much rather use some form of object database and
> something like XML-RPC for interop.  So, yes, I would consider GOODS.

No legacy data. Fresh new app.

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

> As for "ad-hoc" queries: you'll have to be more specific.  The only
> way that relational databases offer ad-hoc querying is if the user
> types in SQL themselves.  Is that what you would do?  Otherwise,
> you're providing a structured UI for the user to enter their query,
> and so you know ahead of time what kinds of queries might be used and
> can structure your object model and your indices accordingly.
>

Pretty much is the second form. Meaning, there would be pre-defined 
reports where the user will have the ability to specify certain 
criteria from a pre-defined set of parameters.

Anyway, you continue to provide insightful information and hope you can 
still point me in the right direction.

Thanks again,
Daniel Salama