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

> Hmm... I suppose the closest alternative we have would be to store the > base template name in a variable and pass it in from the view. > If code for support template inheritance lives in views, it's not convenient. Here is code, that implement this feature for Django 1.4/1.9:

Re: MySQL data loss possibility with concurrent ManyToManyField saves

First of all, I would like to say that I strongly support the move to READ COMITTED, including backporting it to 1.8.x. But we also need to explain: REPEATABLE READ is a higher transaction isolation level than READ COMMITTED. If you have problematic code, it should lead to more deadlocks

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

> > > Either way, I fail to see how that feature would be really useful. > I was need a refactor for large hierarchy of django templates. Moving branches inside hierarchy is simple, if inheritance uses relative paths. -- You received this message because you are subscribed to the Google

Re: MySQL data loss possibility with concurrent ManyToManyField saves

On 21 Mar 2016, at 01:25, Cristiano Coelho wrote: > > What performance changes can you expect doing this change? It is probably > that default on MySQL for a good reason. Barring implementation weirdness, reducing the isolation level is supposed to improve

Re: MySQL data loss possibility with concurrent ManyToManyField saves

I'm strongly -1 on changing the default isolation level in a minor release. We can recommend users switch the level and complain loudly if they don't. But just changing the isolation level has potential for breaking working code. - Anssi On Mon, Mar 21, 2016 at 9:27 AM, Shai Berger

Re: MySQL data loss possibility with concurrent ManyToManyField saves

My recommendation to backport is based on the observation that the peculiar REPEATABLE READ behavior is highly conductive to data loss in the presence of concurrency, combined with a sense that it is not very well known; I find it much more likely that the change will fix broken code than break

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

On Monday, March 21, 2016 at 8:25:46 AM UTC+1, Vitaly Bogomolov wrote: > > Here is code, that implement this feature for Django 1.4/1.9: > https://github.com/vb64/django.templates.relative.path >

Re: MySQL data loss possibility with concurrent ManyToManyField saves

This being MySQL I wouldn't be surprised if changing the isolation level would introduce new problems. Also, user code might rely on Django using repeatable read. If we introduce the change in to stable releases, we risk breaking sites that work perfectly well currently. To me this is against our

Re: MySQL data loss possibility with concurrent ManyToManyField saves

We’ve had, and known about, such problems for so long that I’m also inclined not to make that change in already released versions. -- Aymeric. > On 21 Mar 2016, at 12:33, Anssi Kääriäinen wrote: > > This being MySQL I wouldn't be surprised if changing the isolation > level

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Hi, I'm the ticket OP. As a user, I definitely expect that my ORM won't eat my records when I save something, even with concurrency. Furthermore, I expect it to work with the default configuration of the backend, or if I have to change it, the ORM should refuse to work until the configuration

Feature suggestion: Count database queries

Hi, When working with large projects, it is sometimes the case that you run into problems where some edge case causes a pathologically high number of queries for processing a specific request. These cases are hard to debug, because it is not always easy to reconstruct the edge-case and even

Re: [GSoC 2016]Proposal: Validity check at client and dynamic form framework

I don't have enough enough knowledge on how GSoC works and what the django team expects from people proposing projects but if it was me I would rather have a very well implemented, tested and with a good level of customization client side validation than two not so well features but that's up

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Shai Berger, this explanation is pure gold! Definetely better than MySQL's one. Now I may agree on that changing the isolation level should be probably left to a major release, or either have a huge warning on the patch notes. I personally can't think of any project I have done that this

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Hello, > On 21 Mar 2016, at 12:01, hcharg...@medici.tv wrote: > > In my opinion, the fix should not be to set a different default isolation > level, as that could trigger other problems that may be very hard to find. I > was lucky to find this one. I think that Django should find sequences of

Re: Feedback on Django Channels

On the static files question, I'm about to release v3 of WhiteNoise (http://whitenoise.evans.io/en/latest/changelog.html) which provides the option to integrate via Django middlware, rather than wsgi middleware. (It uses the FileResponse class, which didn't exist when I first wrote

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Le lundi 21 mars 2016 13:35:19 UTC+1, Aymeric Augustin a écrit : > > > The problem is to determine what “safe” means here :-) I’m afraid this > won’t be possible in general (at least not in a remotely efficient fashion) > because Django inevitably depends on the guarantees of the underlying >

Re: Feedback on Django Channels

How does the new channels model handle requests with sensitive information? Say you have a login view and the user is submitting a username/password. Does the password get serialized into the message queue as plain text? If so is that a security concern users should be aware of? Sean On Mon, Mar

Re: Feedback on Django Channels

On Mon, Mar 21, 2016 at 9:55 AM, David Evans wrote: > On the static files question, I'm about to release v3 of WhiteNoise ( > http://whitenoise.evans.io/en/latest/changelog.html) which provides the > option to integrate via Django middlware, rather than wsgi middleware. (It

Re: Feedback on Django Channels

On Mon, Mar 21, 2016 at 12:11 PM, Sean Brant wrote: > How does the new channels model handle requests with sensitive > information? Say you have a login view and the user is submitting a > username/password. Does the password get serialized into the message queue > as plain

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

There are backwards-compatibility concerns as a leading dot can no longer be used in a template name, though if developers are following the advice about template namespacing it wouldn't be a problem. Still, I am not sure if the Django Template Language should evolve new features like this. Is

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

> > There are backwards-compatibility concerns as a leading dot can no longer > be used in a template name, though if developers are following the advice > about template namespacing it wouldn't be a problem. > Mimicking for python import paths it's just my proposal. If this violate some

Re: MySQL data loss possibility with concurrent ManyToManyField saves

On 21 Mar 2016, at 15:02, Hugo Chargois wrote: > > But here, we have "two non-conflicting updates (no-ops, even) causes data to > be lost". I bet no one would call this safe. Yes, this one was clearly a bug (and, if I understand correctly, it was resolved by a

code.djangoproject vs docs.djangoproject

Hi! I just made a ticket, and want to follow it up and fix some of the links on the Django resources page. Where is the source for the code.djangoproject? Is it in the same repo as the Sorry if this is in the docs; I'm trying to figure out

Re: Index expressions

Hello, Tim. Is there free tasks for me, I'm a new one in django(0.5 year), but it's really interesting for me and I want to be useful for us and have a good summer with great experience. waiting your answer and making a contribution, Alex -- You received this message because you are

Re: code.djangoproject vs docs.djangoproject

Copying my response from the ticket, "The wiki isn't part of the official documentation so a Trac ticket isn't needed. Just make sure you are logged in and use the "Edit this page" button at the bottom of the page. Thanks!" On Monday, March 21, 2016 at 2:41:54 PM UTC-4, Becka R. wrote: > > Hi!

Re: Index expressions

Sorry, but if you haven't started a proposal yet and haven't contributed to Django before, it's unlikely you'll develop a successful proposal in less than a week (the application deadline is Friday). On Monday, March 21, 2016 at 2:59:43 PM UTC-4, aleksand...@gmail.com wrote: > > Hello, Tim. > >

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Hi, On Monday 21 March 2016 13:01:27 hcharg...@medici.tv wrote: > > I agree with Karen that documenting that some functions don't work is not > helping. Especially since this is Django's fault, not MySQL's. I mean, > sure, MySQL has some very weird isolation modes, I definitely agree with > Shai

Re: Feedback on Django Channels

Assuming the frontend has access to DJANGO_SETTINGS_MODULE, couldn't it use the SECRET_KEY to encrypt the message before passing it to the message broker? On message receipt it could then use the SECRET_KEY to decrypt the message. It'd be nice if encryption were an option encoded within the

Re: Feedback on Django Channels

The channel layer could indeed use SECRET_KEY, since it's loaded in via a Django codepath in both the protocol server and the worker server. It's better done as a channel layer feature rather than in Channels/Daphne directly, as then it requires no extra supporting code in anything else that does