Re: To keep or not to keep: logging of undefined template variables

+1 to overridable function. Subclassing the whole Engine would be somewhat cumbersome to just set up errors for invalid variable cases. Dne neděle 24. ledna 2021 v 18:20:58 UTC+1 uživatel tim.mc...@gmail.com napsal: > I was going to have a go at this ticket ( > https://code.djangoproject.com/ti

Re: Revisiting Python support for after Django 3.2 LTS

Hi y'all, I think we should keep the current policy. There is never a good time to drop support for anything and extending support especially for Python 3.7 will end with more exceptions in the future. Current policy is really patronizing and with the new Python release schedule we can reac

Update returning

Hi, I found myself with a use-case today of wanting to return some data from an update, as I want to make sure I return exactly what is in the database without making an extra query. I've found https://code.djangoproject.com/ticket/28682 and agree with the resolution there. I suppose there is a

Re: Update returning

I think we could do the most logical: QuerySet.objects.update(name="Rob", returning=["id', "name"]) There is a precedent for small backwards incompatible changes like this, for example when "named" was added to "values_list()". However maybe backwards compatibility is worth keeping. We can be bac

Re: Update returning

Not that I am completely convinced that the following is a good idea; but what about: QuerySet.objects.update(name="Rob").values("id", "name") On second thought I'd like an .returning() more than values, but I am not sure if it makes sense to add a new function just for the sake of a small bac

Re: Update returning

> > Not that I am completely convinced that the following is a good idea; but > what about: QuerySet.objects.update(name="Rob").values("id", "name") > That's not possible since update() directly performs the update - it's not lazy in any way. It could be done in the other order like `QuerySet.obj

Re: Update returning

On Tuesday, January 26, 2021 at 5:26:02 PM UTC+1 Adam Johnson wrote: > Not that I am completely convinced that the following is a good idea; but >> what about: > > QuerySet.objects.update(name="Rob").values("id", "name") >> > > That's not possible since update() directly performs the update - it

PR review request

Django committers, The docs recommend posting here if a pull request hasn't seen any action in awhile—I'm sorry if this nudge is premature! There are a couple of PRs I'd love to get merged into 3.2 before the

Re: PR review request

Hi William, 3.2 alpha marked the feature freeze. Only non-release blocking bug fixes may be backported at this point (from https://code.djangoproject.com/wiki/Version3.2Roadmap#schedule). There are 28 other patches in the review queue, many of which have been there longer than your tickets, so

Re: Revisiting Python support for after Django 3.2 LTS

Looking at this again, I'm not sure it would be six versions. Carlton's suggested policy has the effect of dropping a lot of Python versions right before the LTS since it's supported for 3 years. For example, in Django 5.2 LTS, I think it's incorrect that Python 3.10 and 3.11 would be supported

Re: Snowflake db backend

In order to release the code, I need to provide a sustainment plan per our open source committee. Which is why I was reaching out. I can share some of the challenges conforming Snowflake to the SQL model Django uses. It sounds like we may have had similar experiences writing backends, but pos

Re: Update returning

If we were to change the update signature from (**updates) to (updates=None, *, returning=None, **kwargs) the `returning` collision could be avoided by doing update({"foo": "bar"}, returning=["id", "foo"]) like Tom is suggesting. I think that's the best option here if we want to elegantly add s