-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oleg Broytmann wrote: > On Mon, Feb 02, 2009 at 12:38:45PM -0500, Stef Telford wrote: >> Oleg Broytmann wrote: >>> On Sun, Feb 01, 2009 at 06:25:07PM -0500, Stef Telford wrote: >>> 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. > > I know. I did it many time in this mailing list - inadvertently > offended people. Different levels of English knowledge, different > vocabularies, different understanding... >
Well, don't worry about your english, I am scottish - NO one understands me usually when I talk ;) I dare say, your english is better than (I am guessing) my russian (??) so, not a worry/concern. >>> 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 > > Aha, I see. We are talking about different concepts. You are > talking about database isolation. I am talking about python shared > variables. Those locks in the code protect python variables, not > database! Think about that very pool, connection._pool - nobody > (i.e., no other thread) should read it even less should write to it > until SQLObject finishes manipulating it. The same is true for > alias lock. > Ah, getting rid of the writelocks for connection pooling isn't a worry (I was thinking of getting rid of that and letting the framework deal with that instead). However, what is the alias lock for ? In the scenario I plan on using SQLObject in, would an alias lock even be required/needed ? alias's will stay 'fixed' at webserver/framework launch .. no ? >> 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. > > But what was you plan from the beginning? If you were going to have > a forked version of SQLObject - wouldn't fork and catching up the > only option? You can add some code to the very SQLObject, but if > you want to remove some generic code - what is the way? > Actually, I -had- hoped that SQLObject could have writelocks enabled/disabled, same for connection pooling (which you tell me it does, which is great), caching enabled/disabled (the version inside SQLObject). The queryCaching I do currently by using python's 'global' in the servlet , I can't imagine that going into the main SQLObject (and it probably shouldn't). I could put that in a derived class from the framework Servlet itself. Let me jst say that I have had -bad- previous experience with forks of projects and libraries. Invariably they start to become more and more incompatible. I would prefer -not- to get into that situation if possible. Actually, is it possible to get (under subversion) a delta of patches from one version to another but cherry picking the changes to be made ? That's the one thing under git that would make things .. 'bearable' at least. Thank you for your time Oleg, I know my emails may seem to be strange, especially if english is not your first language. It is truly appreciated. Regards Stef > Oleg. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJh1KUANG7uQ+9D9URAqsjAJ9Y9z3O7b1hMt1ZwrpuX/mKsEmcwQCfVg89 05Vbk+mOwUeRTDqI+HxDnXQ= =1/yh -----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
