-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oleg Broytmann wrote: > 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. :) >
good show. I always get worried about people taking offense over e-mail. I find that tone is very hard to convey. >>>> *) 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? > Well, at the start of every request, a connection is created to the database. Now, -any- rdbms worth it's salt basically creates an isolation level so that I can see -my- changes but no one else's changes, and it also 'locks' any items that are updated - thus avoiding update contention. The -database- should handle this in other words, rather than trying to put the problem onto the application to deal with this, let's let the database handle it. I assume that this is what the writeLocks are trying to do (stop different threads from updating the same item at the sametime). I understand that RDBMS rules out mySQL (not flamebait, merely saying that ACID isn't really "there" on mySQL to my liking). Perhaps I haven't dug far enough into sqlobject's code yet. but if all the objects are instantiated in one thread, the thread runs at the start of the request through until the end of the request before going back to the threading pool, then why is threading.lock() even needed ? how can another process 'jump' or assume thread control (assuming the framework doesn't call yield, which it doesn't ;) ? perhaps I misunderstand python's threading model. The globals table (as far as I can tell) contain a list of tables and expressions for sqlbuilder.. when would these change -without- me having to restart the webserver ? if I change the schema of an object in the database, I would expect to bounce the webservers, right ? >>>> *) 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. > The count should could change inside a transaction, but the web 'workflow' doesn't really mix page rendering and saving in one transaction. If a save requests come in, I would expect a new connection to be forked, all the work done in 'updating' in that one, and a 'read' connection which only EVER deals with 'reads'. I don't think this use case is really much different from how most web frameworks work. A mixed read+update style in a single connection, personally speaking, would seem like -making- work for myself ;) >>>> 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. :( > ah, sorry to hear that. Hrm. alright. this does raise a certain amount of .. concern. I think this end up being the -real- problem (no offense meant again :). I don't mind tidying up and putting in memcache support and master/slave style connections for a web version, but I obviously don't want to play 'catch up' with every new release that you fellows do.. hrm. Regards Stef > Oleg. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhy+gANG7uQ+9D9URAiAGAJ0atjrZ8hHjxQRW/oLES6ju57CewQCbB94l sREC4Wlep8lOhF5WlNCUAMk= =msNB -----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
