Re: MySQL data loss possibility with concurrent ManyToManyField saves

On Wednesday 23 March 2016 11:50:59 Hugo Chargois wrote: > > ... MySQL's REPEATABLE READ may have > it flaws, it may cause repeating bugs because that level is a bit awry, > with its reads and writes that don't work the same, but all in all, it IS a > higher isolation level than READ COMMITTED.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

While there are some different opinions expressed here (mine included), the rough consensus seems to be to apply the for_update() patch to 1.8.x (it is neither needed nor applicable to 1.9.x) and change the transaction isolation level for 1.10 and going forward. To the best of my knowledge,

Re: MySQL data loss possibility with concurrent ManyToManyField saves

What's the current status on this? Is the .for_update() change mentioned in the bug report the best way to go? Is anyone working on a PR? On 03/18/2016 05:15 PM, Karen Tracey wrote: This is the 2nd major issue I can recall caused by MySQL default of REPEATABLE READ transaction isolation level.

Re: [GSoC 2016] Please Critique (Condition API - Related to Auth)

Hi Connor, Overall I find it pretty cool that work on this has been started. There are a few questions I'd like to ask on this proposal. In this example: class ReadingDelete(UserPassesTestMixin, DeleteView): model = Reading def test_func(self): user =

[GSoC 2016] Please Critique (Condition API - Related to Auth)

Hello Everyone, I would love to hear your critiques on my proposal and original idea for GSoC 2016, hopefully before the deadline tomorrow–although I plan on pursuing it no matter what, so any critique at any time would be welcome

Re: relative path in {% extends "...base.html" %} like relative import

> > Yes, the patch must contain a call to posixpath.join somewhere. This is > tricky to get right, don’t reinvent the wheel! > Agree, posixpath is the best solution. Forgot this module :( -- You received this message because you are subscribed to the Google Groups "Django developers

Revisiting lazy middleware initialization

Hi all, Currently, middleware is initialized lazily on serving the first request, rather than on application start. There may well have been good reasons for this historically, but I don't think they apply any longer. Lazy initialization is unhelpful if a middleware class throws an error (e.g

Re: relative path in {% extends "...base.html" %} like relative import

On 24 Mar 2016, at 01:07, Tim Graham wrote: > Asking again... I am not sure if the Django Template Language should evolve > new features like this. Is there any prior art in Jinja2? Absent any other > +1's, I guess I would be more comfortable accepting the feature if so.

Re: relative path in {% extends "...base.html" %} like relative import

On Thu, Mar 24, 2016 at 05:06:54AM -0700, Vitaly Bogomolov wrote: > > The code seems too complicated. Could we reuse os.path handling from the > > standard library to simplify it? > > > > I don't think, that os.path is applicable in this case, because > template_name != file_name. In fact,

Re: relative path in {% extends "...base.html" %} like relative import

> > Asking again... I am not sure if the Django Template Language should > evolve new features like this. Is there any prior art in Jinja2? Absent any > other +1's, I guess I would be more comfortable accepting the feature if so. > I can't say anything about Jinja2, but for existing old

Re: GSoC

Sorry but there isn't enough time left to put together a successful proposal. It takes weeks to do that, not hours. Start your involvement with contributing to Django now and you'll have a better chance next year: https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

GSoC

Hello and Season Greetings, I am trying to apply for the GSoC 2016 But am almost late for the deadline and was requesting for help from the community. I am a newbie to Django but would really love to be part of this great experience. Please assist Kind Regards. -- You received this message