-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 :)
>> *) 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.
>> *) 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 ;)
>> *) connection pooling - I would have thought (again perhaps
>> naively) that in a web environment, this should exist outside the
>> ORM.
>
> It is easy to disable: connection._pool = None.
>
interesting. Noted (and thank you) - I guess I am still stuck in
request->response thinking. The connection seems to be screaming
'Singleton' or 'Borg' to me.. but.. perhaps that's jst me :)
>> 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
Thanks for the prompt reply btw :D
Regards
Stef
> Oleg.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJhi9TANG7uQ+9D9URAhYJAJ42WZQe/gICkU+imbDvxFIiTjc4ywCfbLh1
n9+b02Wj0s1wJeTc2jX8ctA=
=+tq3
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
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
