Re: [SQLObject] RFP: SQLObject-Web ?

[David T. <no...@op...>]

On Sun, 2009-02-01 at 18:25 -0500, Stef Telford wrote:
> Hello Oleg,
> 
> Oleg Broytmann wrote:
> > Hello!
> >
> > My company uses SQLObject solely for desktop applications.
> >
> Understandable, and this is pretty much how I was thinking SQLObject
> was designed/targetted for. This makes perfect sense, but in a web
> framework perhaps not as much. No offense meant ;)
> > On Sun, Feb 01, 2009 at 03:49:46PM -0500, Stef Telford wrote:
> >> *) There is writeLocks - surely not required since most
> >> frameworks run the entire thread under a transaction anyway.
> >
> > I don't see how a web transaction is related to multithread-safe
> > locks. Whatever a web transaction is, there are a lot of different
> > web frameworks, and who guarantees it is thread-safe to touch
> > shared variables?
> >
> well, from what I have seen over the years, most web frameworks that
> use an ORM do the following;
>     start request handling in a thread
>         create connection to db
>         do processing
>         commit connection/rollback capture
>     end request
> 
> I know that's -very- high level, but, there is never really any
> contention in such an environment and, therefore, there is no need for
> writeLocks. I am thinking of webware here, probably Turbogears from
> what I can recall and .. you get the idea. so, I am suggesting that
> the web edition get's -rid- of writeLocks :)

This is also how some of my Pylons-based applications work, fwiw.  I
would definitely use this.

> >> *) no query caching
> >
> > What is a query in terms of an ORM? If 'document' is an SQLObject,
> > attribute access like 'document.title' is implemented using a SQL
> > query. How does query caching help? In any case - if query caching
> > helps, SQLObject will benefit if somebody commits a code, right?
> >
> True.. true. I have rudimentary queryCaching but, as I said, it only
> - -really- makes in the servlet/web response scenario above. I noticed
> that SQLObject issued a lot of similiar sql calls, again, mostly due
> to the object heavy pages we have/use. In -your- usage of SQLObject,
> the query cache would probably be a lot more pain than it is worth. We
> would have to hook into setattr on sqlojbect, get the class name and
> id, then walk over the queryCache checking if that update invalidates
> any of the cached queries.. major pain and probably not worth it.
> 
> In -my- usage pattern, it makes a lot of sense. Sometimes a page calls
> .count() more than 20 times for the same query/object. Poor design ?
> perhaps, however I think that the 'path of least surprise' is that
> SQLObject would 'cache' that query and return the cached value since
> we are inside the same request/response cycle.
> 
> Again, this is totally understandable given how -you- use SQLObject ..
> I am merely wandering if it may make sense to make a more .. well ..
> 'web-centric' version. I could be totally wrong here, of course, hence
> why it's a RFP ;)

I'm less interested in this one, because I usually just use a
per-request cache when I need one.