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. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
