Amit Upadhyay wrote:
> 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
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'
>>
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
On Fri, Oct 17, 2008 at 6:07 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> > I do not understand, when everywhere django tries so very hard in a
> > pragmatic sense to decouple things where it logically makes sense, then why
> > suddenly an ideological outburst of "because we are not violating
On Fri, Oct 17, 2008 at 7:10 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> To reiterate, I am proposing: "avoid, and if not possible, document" for DB
> updates in GET, are you really saying you are against this? Is your logical
> position "encourage" or "don't care/document"?
To reiterate, I
On Fri, Oct 17, 2008 at 4:03 PM, James Bennett <[EMAIL PROTECTED]>wrote:
>
> On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> > Either this becomes a django standard, every code that might update
> database
> > on GET doing something like:
> >
> >
On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Either this becomes a django standard, every code that might update database
> on GET doing something like:
>
> connection.use_master()
> try:
> ... # something that updates db
>
On Wed, Oct 15, 2008 at 9:25 PM, bo <[EMAIL PROTECTED]> wrote:
>
> It seems that what you may want is something like
>
> http://softwaremaniacs.org/soft/mysql_replicated/
The crux of that solution is the middleware:
def process_request(self, request):
state = request.method in
On Fri, Oct 17, 2008 at 12:54 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Thu, Oct 16, 2008 at 7:11 AM, Rajeev J Sebastian
> <[EMAIL PROTECTED]> wrote:
>> Without trying to read deeply between the lines, the thread seemed to
>> come to a point where the one choice would be to document the
On Thu, Oct 16, 2008 at 7:11 AM, Rajeev J Sebastian
<[EMAIL PROTECTED]> wrote:
> Without trying to read deeply between the lines, the thread seemed to
> come to a point where the one choice would be to document the cases
> where in the core (i.e., django+contrib) a GET request could cause a
> db
Hi Ned,
On Thu, Oct 16, 2008 at 5:22 PM, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> At one point, Amit used the phrase "should Django enforce it?", which sounds
> like more than documentation to me. Changing Django so that GETs couldn't
> modify the database would be a bad idea. There are
bo wrote:
> It seems that what you may want is something like
>
> http://softwaremaniacs.org/soft/mysql_replicated/
>
> (its in Russian that i cannot read and one of the links has the
> source :)
It has a link saying "English" right on top of the page :-). It's
It seems that what you may want is something like
http://softwaremaniacs.org/soft/mysql_replicated/
(its in Russian that i cannot read and one of the links has the
source :)
master slave DB engine (for Mysql)
I modified it to force a master call for everything that was not a
"SELECT" in the
On Wed, Oct 15, 2008 at 6:40 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> While I can see the generic desirability of GET requests not making
> database writes there are always going to be exceptions. Let's not
> pursue this as a purist goal, but rather for the sound pragmatic reasons
> that
Amit Upadhyay wrote:
> On Wed, Oct 15, 2008 at 5:17 PM, Ivan Sagalaev
> <[EMAIL PROTECTED]> wrote:
>
>> Amit Upadhyay wrote:
>>
>>> This is not about specs or what is allowed, rather what is there in
>>> actual django. And about implementation goals for django. It is
>>> possible to have
On Wed, Oct 15, 2008 at 5:17 PM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
>
> Amit Upadhyay wrote:
>> This is not about specs or what is allowed, rather what is there in
>> actual django. And about implementation goals for django. It is
>> possible to have a django(core+contrib apps shipped with
Amit Upadhyay wrote:
> This is not about specs or what is allowed, rather what is there in
> actual django. And about implementation goals for django. It is
> possible to have a django(core+contrib apps shipped with django) with
> only SELECT queries in response for GET request. So far I have
>
On Wed, Oct 15, 2008 at 4:28 PM, Luke Plant <[EMAIL PROTECTED]> wrote:
> It is not desirable to have Django try to enforce this, since GET
> requests are allowed to have side effects, just not side effects that
> "have the significance of taking an action other than retrieval" [1].
This is not
On Wednesday 15 October 2008 10:12:35 Amit Upadhyay wrote:
> My wish for django would be, either 1. a position that other than
> the Session, there is no data changes by entire django if request
> method is GET. or 2. a wiki/doc page explaining what all database
> changes that can happen as part
On Wed, Oct 15, 2008 at 1:55 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> By the way, for something like sessions, the scaling solution is not to
> use server-side storage at all for the session data. Typically sessions
> don't actually hold that much data and even in cases like, say, a
>
On Wed, 2008-10-15 at 13:20 +0530, Amit Upadhyay wrote:
[...]
> One way of
> doing it is based on request.METHOD[1], GET requests going to slave,
> and POSTs going to master.
Be careful, though, since that can lead to problems. Every time you
write to a master, it takes a finite amount of time
On Wed, 2008-10-15 at 13:20 +0530, Amit Upadhyay wrote:
> [So far using non
> db based session backend, and allowing delete for auth_messages from
> "GET machines" and living with "a message appears more than once" is
> what I am doing].
By the way, for something like sessions, the scaling
On Wed, Oct 15, 2008 at 1:20 PM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Question: 1. is the expectation that GET request should only do SELECT
> reasonable? 2. if 1, then should django enforce it?
Clarification, enforce is ambiguous:
Question2.1. django, core and contrib apps shipped with
Usecase: for scaling a website(bottlenecked on database), one of the
first thing to do after caching and other optimizations is to split
requests to go to master/slave replicated database servers. One way of
doing it is based on request.METHOD[1], GET requests going to slave,
and POSTs going to
24 matches
Mail list logo
