On 19 févr. 2013, at 11:04, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
> Maybe we need another setting for what to do in request.start. It does > seem somewhat likely that users could do SET SEARCH_PATH in middleware > to support multitenant setups for example, and expect that set to go > away when connection is closed after the request. Any other SET is a > likely candidate for problems in PostgreSQL, and I am sure other DBs > have their equivalent of session state, too. (In this case doing RESET > ALL; run connection setup again is the right thing to do in > PostgreSQL). > > It would be nice to support this use case, but just documenting this > change clearly in the release notes, and point out that if you have > such requirements, then set max_age to 0. More features can always be > added later on. Yes, the short term solution in this case is to set max_age to 0. I think the long term solution is to modify such middleware to revert its effects in process_response() — or reset everything in process_request(). I agree with Carl that I should document this thoroughly. > (…) > I hope this discussion is about what to do at request finish/start > time. You're right, it's very important not to fiddle with connections during request processing. > I am very strongly opposed to anything where Django suddenly changes > connections underneath you. At request finish/start this is OK (you > should expect new connections then anyways), but otherwise if you get > broken connection, it isn't Django's business to swap the connection > underneath you. There is a reasonable expectation that while you are > using single connections[alias] in a script for example, you can > expect the underlying connection to be the same for the whole time. > Otherwise SET somevar in postgresql could break for example. Even worse, you could break transactional integrity! See this comment: https://code.djangoproject.com/ticket/15119#comment:9 > I think a good approach would be to mark the connection potentially > broken on errors in queries, and then in request_finished check for > this potentially broken flag. If flag set, then and only then run > ping() / select 1. So, this is a slight modification of no. 3 where > one can mark the connection potentially broken liberally, but the > connection is swapped only when the ping fails, and only in > request_finished. For most requests there should be no overhead as > errors in queries are rare. This is an interesting idea. Django already catches database exceptions in execute() to re-raise them. We could simply set the flag there. > BTW the remark above in Aymeric's post that persistent connections > can't make things worse: I don't believe this. Persistent connections > will keep the broken connection from request to request, and at least > on PostgreSQL a broken connection is correctly closed in request > finish. https://code.djangoproject.com/ticket/15802 says it isn't — although I haven't confirmed that this bug still exists. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
