On Fri, Oct 17, 2008 at 7:10 PM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
>
> Amit Upadhyay wrote:
>> The crux of that solution is the middleware:
>>
>> def process_request(self, request):
>> state = request.method in ['GET', 'HEAD'] and 'slave' or 'master'
>> connection.use_state(state)
>>
>> Which is same as what I am talking about.
>
> I feel obliged to correct this. It's not the crux in any way but a
> convenient method of eliminating *most* but not all of hand work from
> managing connections.
Yeah, but how will you manage the connections in the cases this fails,
when the connection is being used from django core, but by patching
django in the fashion I mentioned above? You will have to go read
entire django, find all views/middlewares shipped with it, and up the
lines like these on the offending part.
connection.use_master()
try:
... # something that updates db
finally:
connection.revert()
You can not manage connection used by django[core + contrib apps that
comes with it]!
> As many have pointed out such pure systems where
> GET doesn't touch any state just don't exist.
>
> Unfortunately practice is more complex than theory and attempts to
> ignore it lead to systems that nobody uses.
This is not true.
Do this:
1. make sure none of your apps do db writes on GET. [It was the case
with my entire project already, other than one case, which was trivial
to work around].
2. Use non db session backend.
3. Not use auth messages. [This presented some problems for me, but I
had luckily using wrapper for message creation and not
User.message_set.create() as recommended in docs; after porting
http://code.djangoproject.com/ticket/4604 to my django-0.96, all I had
to do was to change few lines here and there].
And you have a safe "pure systems where GET doesn't touch any state",
which is not complex and I use it at my website!
It was kind of trivial in my case, I checked: none of the queries were
modifying anything by granting only SELECT perms to user handling GET
app/slave and testing all functionality of my website.
If the prevailing mood is to be trusted, one would get an impression
that the GET write db situation is so messed up in django, that this
request.method based splitting for load balancing should not be
considered at all. So many people may be getting misdirected by this.
But then I can not say this for certainity for all django powered
projects. There might be other bits lurking in parts of django I did
not use/test, and some more may come in future in the bits I used and
tested against, if django developers do not consider it something to
think about, and leaves us to go through source code after every
release.
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
