[Seaside] Re: Scaling Seaside apps (was: About SToR)
yanni at rogers.com
Sat Aug 5 15:28:23 UTC 2006
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
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.
More information about the Seaside