[Seaside] Fast text search and proper design

[Yanni Chiu]

Benjamin Pollack wrote:
> I ended up
> having a series of class-side statements that fetched and saved
> objects (e.g., UMovie>>moviesWithTitleContaining:usingConnection:),
> but I can't shake the feeling that this is a poor OO design.

That may or may not be poor design, depending on how much
generic code is shared across all your classes - see the
abstract persistent class approach below. The way class side
behaviour is inherited in Smalltalk makes writing generic
frameworks much easier than in Java and C++.

> What design is generally considered proper for this purpose?

IME, there a two approaches. You use an abstract persistence
class from which all your model classes inherit. Each model
class has metadata which the persistence superclass uses to
to perform the necessary data access (e.g. generate SQL).

The other approach is much the same thing, but delegates to
a data access subsystem which probes the model to generate
the SQL. The big advantage here is that your model classes
aren't forced to subclass from a given class. But the code is
slightly harder to read, IMHO.

> Do you put the
> SQL and database connection in your Seaside components? In the model
> classes? In the session class? Where?

I think the database connection goes in a Seaside session.
For better performance, the connections could be requested
from a pool, and returned to the pool when the session times
out (or is closed).

> Likewise, whose responsibility should it be to propogate changes?

Don't quite understand what you mean here. I'm guessing you
might want to look at object-relational mapping (see Glorp for Squeak),
but I see you're also considering GOODS (so maybe you can avoid the O-R
mapping swamp, for now).

> For this particular project, I would like to use GOODS rather than an
> RDBMS, but I need the ability to search very quickly through large
> amounts of text and return appropriate matches. I cannot find any
> effective data structure to use for that.

IIUC, much of the tsearch2 (full text search) functionality is
actually written in Perl, along with some utilities done in C.
Much of the interaction with PostgreSQL is allowing queries to
be specified, and of course the bookkeeping of the search index
columns that are added. There's also a few other config. tables.
Hope that helps.

--yanni