[Seaside] Re: Scaling Seaside apps (was: About SToR)

[Yanni Chiu]

Alan Knight wrote:
> I note that as far as Postgresql, my experience is with the driver
> that Bruce Badger did in VW.

Presently, both are based on the postgres v2 protocol.

> ...  or that the postgresql protocol does
> not have a mechanism for passing only part of the results back before
> the remainder has been calculated, or if it's just the driver at the
> Smalltalk level ignoring such protocol and getting everything.

The protocol returns a row at a time until there no more (indicated
by a CompletedResponse message, instead of another Row message). It 
seems both Bruce and I chose to implement in such a way that a result 
set is only available after the last row has been received.

I suppose a better choice (for the future) would return with a
result set stream as soon as the first row is retrieved. Then add
additional protocol to return the entire result set by pulling in
the whole stream contents.

> Glorp doesn't do anything in terms of actually declaring named
> cursors and issuing fetch statements.

That's what I figured, from a quick glance. Thanks for confiming it.

> Glorp will also keep a cache of prepared statements and re-use them
> if the hooks are in place, but I wasn't aware of how to do that for
> Postgresql.

I think the new "extended query" feature of the postgres v3 protocol
is needed for that.

> I haven't gotten around to writing a NoCacheCachePolicy, but it would
> be quite an easy implementation. But be aware that then you lose
> object identity, which means relationships can get confused, and if
> you're writing, Glorp may not properly know whether to insert or
> update (it bases that on knowing whether or not it read the object).

I don't think a "report query" optimization is equivalent to a
no-cache policy. The report query is no longer trying to maintain
any kind of O-R mapping concept.

-- 
Yanni Chiu