On Sun, Feb 01, 2009 at 06:25:07PM -0500, Stef Telford wrote:
> Oleg Broytmann wrote:
> > 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
I don't think it is how and what it's designed for. Its original author,
Ian Bicking, AFAIK, had been working in a web environment.
> framework perhaps not as much. No offense meant ;)
No offence taken. :)
> >> *) 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 :)
Still I don't understand. What do you mean by saying "there is no
contention"? If there are threads and there are shared variables - the
variables must be protected, right? Have I missed something?
There are global counters, e.g. in Alias - how would they fare if
different threads would want to increase them?
> >> *) cache built in at a fundamental level - most web people would
> >> probably feel safer with memcache, currently I don't see anyway
> >> to disable this
> >
> > Probably by writing a Cache class that doesn't cache.
> >
> yes.. I could do that, but then the 'web' edition would have all these
> references to 'cache' laying around that would be confusing for later
> people/programmers. I would prefer to keep code clean and simple if at
> all possible.
Another approach for SQLObject would be to grow an API to disable
caching, similar to how one can disable connection pooling. Setting
connection.cache to None, or a flag in sqlmeta. But the patch to implement
this would be rather big and have to be thoroughly tested.
> >> *) no query caching
> >
> > What is a query in terms of an ORM?
>
> 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.
Even inside one transaction the result of any .count() could change.
But if one is satisfied with caching results of such queries... well, it is
up to her/him, I don't mind having an API for such caching.
> >> So, is it insanity to propose that perhaps there is a
> >> sqlobject-web version?
> >
> > You are welcome to support one.
> >
> Well, there's the rub.. I could fork a new version, and then spend
> most of my time playing catch-up with the 'official' releases of
> SQLObject .. but I don't think that really helps anyone. Is there any
> way of making a git branch and then before a release even flinging
> across an email/changeset ? I don't know your dev process's involved :D
Currently the developers are using Subversion. Worse then, the
development process is a bit stalled as I don't have spare time and other
developers are not active too. :(
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
------------------------------------------------------------------------------
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
