For reference there are some discussions about this
in https://code.djangoproject.com/ticket/13906. The short version of the
discussions is that MySQL is very interesting when it comes to transaction
isolation levels and things like SELECT FOR UPDATE...
I think it would be ok to allow changing
(I sent basically the same email twice because it looked to me like the
first was lost, didn't even show in my outbox :/)
On 23 January 2017 at 21:15, Adam Johnson wrote:
> Sorry for the radio silence, I've been busy at work.
>
> After re-reading things and thinking a bit more about it, I think
Sorry for my radio/email silence, I had a lot of things to do at work and
wanted to think this through a bit more.
Looking again at the warning + check implementation, it is a bit messy. My
goal with the check was to get a message in front of users who need it, but
I suppose the release notes a
Sorry for the radio silence, I've been busy at work.
After re-reading things and thinking a bit more about it, I think Tim's
suggestion of just changing the default in a release is probably the right
idea. The warning + check does seem very bothersome; as Aymeric says, this
is very far from the co
In the end, I don't use MySQL but if a similar change were made for
PostgreSQL, I would find the current approach more annoying (bothering me
about changing defaults over two release cycles) than cautious.
I'm also uncertain that duplicating a deprecation warning in a system check
is a good pre
>
> aside from some very performance-sensitive websites that already worked
> around Django’s bugs
Tbf it's true I already added READ-COMMITTED at work
I’d love if this fix made it into 1.10
On 13 January 2017 at 15:05, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:
>
Hello,
I think there’s been little feedback because this issue is very, very far from
the concerns of most Django users — aside from some very performance-sensitive
websites that already worked around Django’s bugs and will add the
configuration line needed to keep whatever the isolation level
I guess three days is too little time to get a consensus on this. At this
point I'm thinking to defer this from 1.11.
On Wednesday, January 11, 2017 at 9:50:27 AM UTC-5, Patryk Zawadzki wrote:
>
> To add some context, REPEATABLE READ can break get_or_create among other
> things (not sure how man
To add some context, REPEATABLE READ can break get_or_create among other
things (not sure how many invalid tickets Django gets related to that).
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscri
In ticket #27683 [0], Shai proposed to change Django to default to using
the READ COMMITTED isolation level. Some background on the reasons are on
the ticket and in another thread [1] (possible data loss is involved).
The initial approach [2] that Shai put forward is adding a deprecation
warnin
10 matches
Mail list logo
