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

[Vlastimil Zíma]

+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/ticket/28526) -  which links this thread.
>
> Having read the various replies, it seems like there is no shortage of 
> differing views how missing/invalid variables should be treated:
>  - There should be no logging
>  - There should be logging, but full tracebacks are too noisy / not 
> beginner friendly
>  - Full tracebacks are useful
>  - There should be logging but only for the first time an invalid variable 
> is encountered within a template
>  - Some combination of the above with a setting (or settings) to alter 
> behaviour
>  - There should be a setting to make invalid variables raise errors
>
> There is a danger of bloating the number of options/settings and still not 
> catering for what everyone wants.
>
> One way to allow all of these would be to provide a hook to handle raising 
> errors/logging in the case of invalid variables. This would also allow all 
> kinds of custom behaviour, that might be useful for particular cases, but 
> which wouldn't warrant being features of django itself:
>  - log / raise only on particular templates
>  - provide different levels of logging depending on the type of the 
> invalid variable
>  - etc
>
> I originally thought of replacing `string_if_invalid` with an option 
> function `invalid_variable_handler` that points to a function, which would 
> return a string for invalid variables, and could also handle logging/errors 
> at the same time. Perhaps this is too many concerns for one function; 
> although having said that, it's really just one concern - handling 
> invalid/undefined variables. The default function could return 
> `string_if_invalid` during the interim whilst we add a deprecation warning 
> for `string_if_invalid`.
>
> A less destructive option would be to leave `string_if_invalid` as it is, 
> and just move the code that logs/raises errors to a public method 
> `handle_variable_resolve_errors` of Engine(?). This would provide a public 
> API for people to customise logging/raising of errors if they should so 
> wish, by sub-classing `Engine` (and then add an engine attribute to 
> DjangoTemplates??). 
>
> Alternatively, `handle_variable_resolve_errors` could just be another 
> option which would point to the above function, rather than having to 
> subclass Engine.
>
> The very first of these approaches would allow useful things like 
> returning different `string_if_invalid` values for different templates, if 
> debug is on etc. But seems a bit messier.
>
> There are a few more variations on the same theme, in terms of actual 
> implementation, but the basic idea is the same - move logging/raising 
> errors to an overridable function. 
>
> Any thoughts on this would be much appreciated
>
> On Friday, August 25, 2017 at 11:50:27 AM UTC+1 Vlastimil Zíma wrote:
>
>> If anyone is interested, I've cleaned the errors in admin templates:
>>
>> Ticket: https://code.djangoproject.com/ticket/28529
>> PR: https://github.com/django/django/pull/8973
>>
>> The fixes are quite simple. The biggest problem is sometimes to find out, 
>> in which template the bug actually appears.
>>
>> Vlastik
>>
>> Dne pátek 25. srpna 2017 9:28:30 UTC+2 Vlastimil Zíma napsal(a):
>>
>>> Apparently there is number of errors in admin templates. I suggest to 
>>> fix the templates. I my experience, the most cases are missing if 
>>> statements or missing context variables. These can be fixed very easily and 
>>> produce cleaner templates. I consider this much better solution than just 
>>> ignoring error messages.
>>>
>>> As Anthony suggested, the main problem is more often the fuzziness of 
>>> the messages, which do not often properly state template, line or 
>>> expression which is incorrect. This makes it difficult to resolve them in 
>>> some cases.
>>>
>>> Vlastik
>>>
>>> Dne čtvrtek 24. srpna 2017 17:21:38 UTC+2 Tim Graham napsal(a):

 We received a report that shows the large number of undefined variable 
 warnings when rendering an admin changelist page [0]. 

 I'm still not sure what the solution should be, but I created #28526 
 [1] to track this problem: finding a remedy to the problem of verbose, 
 often unhelpful logging of undefined variables.

 I don't think "the end goal of errors raising when using undefined 
 variables" is feasible. My sense is that relying on the behavior of 
 undefined variables is too entrenched in the Django template language to 
 change it at this point. (If someone wanted to try to fix all the warnings 
 in the admin templates, that might provide a useful data point). See the 
 "Template handling of undefined variables" thread [2] for a longer 
 discussion.

 [0] https://code.dj

Re: Revisiting Python support for after Django 3.2 LTS

[Mariusz Felisiak]

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 reach 6 
supported versions of Python for every LTS. I would make it even more 
aggressive :) It's not only about the maintenance burden but also about new 
features and syntax, we have tickets waiting 2-3 years until Python X 
becomes the minimal Python supported by Django. My 2 cents 🤷

Best,
Mariusz

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/63118c58-e698-4662-9d49-a7a2875ae0b7n%40googlegroups.com.

Update returning

[Tom Carrick]

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 way to do this in a backwards compatible way,
something like:

Foo.objects.update(["id", "name"], name="Rob")

But it's very ugly. But how about a new method:

Foo.objects.update_returning(["id", "name"], name="Rob")

Doesn't seem quite so bad. There's also a possibility of something like:

Foo.objects.update_returning(updates={"name": "Rob"}, returning=["id",
"name"])

I'd expect it to return a list of dicts. I'm not sure what's best, if
anything. It could be it's a bit too niche, but it is sometimes quite
useful.

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaDz7VLXqRk01D_bUOLN%3D5TBiqVrw-BzyLogeaTMtXM4g%40mail.gmail.com.

Re: Update returning

[Adam Johnson]

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 backwards compatible by
special-casing models with a field called 'returning', in which case the
field is updated. This blocks the 'returning' functionality but users can
always rename a field.

I'd rather not add a new method or otherwise change the signature of
update() more radically.

On Tue, 26 Jan 2021 at 13:27, Tom Carrick  wrote:

> 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 way to do this in a backwards compatible way,
> something like:
>
> Foo.objects.update(["id", "name"], name="Rob")
>
> But it's very ugly. But how about a new method:
>
> Foo.objects.update_returning(["id", "name"], name="Rob")
>
> Doesn't seem quite so bad. There's also a possibility of something like:
>
> Foo.objects.update_returning(updates={"name": "Rob"}, returning=["id",
> "name"])
>
> I'd expect it to return a list of dicts. I'm not sure what's best, if
> anything. It could be it's a bit too niche, but it is sometimes quite
> useful.
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaDz7VLXqRk01D_bUOLN%3D5TBiqVrw-BzyLogeaTMtXM4g%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3gDEpRyR0035LHREQwhzWrXiHvWqbbN%2BgPkSuv6jMDBw%40mail.gmail.com.

Re: Update returning

[Florian Apolloner]

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 
backwards compatibility.

> I'd expect it to return a list of dicts.

Currently .update returns the number of rows affected I think. This 
information should still be there even if returning extra data.
On Tuesday, January 26, 2021 at 3:00:01 PM UTC+1 Adam Johnson wrote:

> 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 backwards compatible by 
> special-casing models with a field called 'returning', in which case the 
> field is updated. This blocks the 'returning' functionality but users can 
> always rename a field.
>
> I'd rather not add a new method or otherwise change the signature of 
> update() more radically.
>
> On Tue, 26 Jan 2021 at 13:27, Tom Carrick  wrote:
>
>> 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 way to do this in a backwards compatible way, 
>> something like:
>>
>> Foo.objects.update(["id", "name"], name="Rob")
>>
>> But it's very ugly. But how about a new method:
>>
>> Foo.objects.update_returning(["id", "name"], name="Rob")
>>
>> Doesn't seem quite so bad. There's also a possibility of something like:
>>
>> Foo.objects.update_returning(updates={"name": "Rob"}, returning=["id", 
>> "name"])
>>
>> I'd expect it to return a list of dicts. I'm not sure what's best, if 
>> anything. It could be it's a bit too niche, but it is sometimes quite 
>> useful.
>>
>> Tom
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaDz7VLXqRk01D_bUOLN%3D5TBiqVrw-BzyLogeaTMtXM4g%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/abde0155-3eb9-4330-994a-c5f9133b236an%40googlegroups.com.

Re: Update returning

[Adam Johnson]

>
> 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.objects.values("id", "name").update(name="Rob")` but I don't see
the necessity to define "returning" fields in a chainable manner.

On Tue, 26 Jan 2021 at 14:59, Florian Apolloner 
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")
>
> 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
> backwards compatibility.
>
> > I'd expect it to return a list of dicts.
>
> Currently .update returns the number of rows affected I think. This
> information should still be there even if returning extra data.
> On Tuesday, January 26, 2021 at 3:00:01 PM UTC+1 Adam Johnson wrote:
>
>> 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 backwards compatible by
>> special-casing models with a field called 'returning', in which case the
>> field is updated. This blocks the 'returning' functionality but users can
>> always rename a field.
>>
>> I'd rather not add a new method or otherwise change the signature of
>> update() more radically.
>>
>> On Tue, 26 Jan 2021 at 13:27, Tom Carrick  wrote:
>>
>>> 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 way to do this in a backwards compatible way,
>>> something like:
>>>
>>> Foo.objects.update(["id", "name"], name="Rob")
>>>
>>> But it's very ugly. But how about a new method:
>>>
>>> Foo.objects.update_returning(["id", "name"], name="Rob")
>>>
>>> Doesn't seem quite so bad. There's also a possibility of something like:
>>>
>>> Foo.objects.update_returning(updates={"name": "Rob"}, returning=["id",
>>> "name"])
>>>
>>> I'd expect it to return a list of dicts. I'm not sure what's best, if
>>> anything. It could be it's a bit too niche, but it is sometimes quite
>>> useful.
>>>
>>> Tom
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaDz7VLXqRk01D_bUOLN%3D5TBiqVrw-BzyLogeaTMtXM4g%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/abde0155-3eb9-4330-994a-c5f9133b236an%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0ZwMTcxGKoQ4Ch%2Bv85b0hd0CseocioWCFkxTXbgJDCPQ%40mail.gmail.com.

Re: Update returning

[Florian Apolloner]

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's not 
> lazy in any way. It could be done in the other order like 
> `QuerySet.objects.values("id", "name").update(name="Rob")` but I don't see 
> the necessity to define "returning" fields in a chainable manner.
>

Ha, not sure what I was thinking. The sentence below I noted that update() 
would return something but I didn't think that this would break chaining. 
My bad.

I looked further around and `get_or_create` has the nice workaround of 
being able to use `defaults__exact` if it clashes with the `defaults` 
keyword. Sadly we do not have that option here. Truth to be told I do not 
think that many people have fields called returning

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/37efe4e9-4ca7-4ad7-b370-94dd2d27fc86n%40googlegroups.com.

PR review request

[William Schwartz]

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 upcoming beta release. Both PRs' tickets were 
approved as cleanups/optimizations before the 3.2 feature freeze.

   - More important: #32316 's 
   PR-13841 , which reduces 
   use of __file__ at the module level. The PR has already seen one round 
   of review and fixes, so hopefully it's (close to) done.
   - Less important: #32317 's 
   PR-13842 , which refactors 
   the loaddata command. The PR has not yet been reviewed.

Thanks for working with me on these (and several other recent) PRs!

Best,
William

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d6fe9a1d-9b1c-4c2a-b706-540d7e35b329n%40googlegroups.com.

Re: PR review request

[Tim Graham]

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 for future reference, I'd say no need to write to the 
mailing list at this point. If you have any colleagues, you could ask them 
to review your patches and mark the ticket as "ready for checkin" if 
appropriate.  Only the final review is limited to Django's team of mergers.

On Tuesday, January 26, 2021 at 3:01:23 PM UTC-5 wksch...@gmail.com wrote:

> 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 upcoming beta release. Both PRs' tickets were 
> approved as cleanups/optimizations before the 3.2 feature freeze.
>
>- More important: #32316 's 
>PR-13841 , which reduces 
>use of __file__ at the module level. The PR has already seen one round 
>of review and fixes, so hopefully it's (close to) done.
>- Less important: #32317 's 
>PR-13842 , which 
>refactors the loaddata command. The PR has not yet been reviewed.
>
> Thanks for working with me on these (and several other recent) PRs!
>
> Best,
> William
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cf32f567-c886--83f4-54bec01a0f60n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Graham]

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 
since their support expires in Oct 2026 & 7, before Django 3.2's expiration 
in April 2028)? The current policy means we have Django LTS's supporting 
some Python's well after they expire. I never liked that aspect of it. 
Anyway, the decision won't affect my life.
On Tuesday, January 26, 2021 at 5:32:50 AM UTC-5 Mariusz Felisiak wrote:

> 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 reach 6 
> supported versions of Python for every LTS. I would make it even more 
> aggressive :) It's not only about the maintenance burden but also about new 
> features and syntax, we have tickets waiting 2-3 years until Python X 
> becomes the minimal Python supported by Django. My 2 cents 🤷
>
> Best,
> Mariusz
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4dd42d46-ffe7-432f-8572-5a261c4fd0fcn%40googlegroups.com.

Re: Snowflake db backend

[Scott Fought]

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 
possibly we differ in completeness.  I was able to write a working backend 
that met all of our application needs in about 3 weeks.  Conforming to the 
unit tests is another story.  We pass ~90% of the tests, but that last 10% 
will take a lot more effort to complete.

For reference, we're using the snowflake-connector-python module, 
which implements PEP 249, v2.0.

Snowflake does not support lastrowid.  So, we grab the last ID inserted 
with a 'SELECT MAX(pk_name) FROM table_name'.  This is obviously prone to 
failure.  Assigning an ID during the INSERT would provide similar results 
on all backends.

The feature flag `supports_transactions` really means 
`supports_nested_transactions`.  Snowflake supports a single level of 
transaction, BEGIN + (ROLLBACK|COMMIT).  Multiple BEGINS contribute to the 
current (only) transaction.  Since I have to set this flag to False, no 
transactions are used, even ones that are supported and testing grinds to a 
crawl with all of the table truncations and repopulation.  Since Django 
*normally* operates in auto-commit mode, this isn't a huge deal.  Snowflake 
also doesn't support save points, but the feature flag seems to do what is 
expected when disabled.

Snowflake does not support column references without a FROM or JOIN clause. 
 I've only encountered this used in the unit tests.

I've been able to work around most of the function differences by adding 
as_snowflake methods to the appropriate classes.  There are a few cases 
like JSON_OBJECT that don't translate well, which work, but not entirely as 
expected.

A search for 'connection.vendor == ' in the core code shows one example of 
where core backends are given privileged access to core Django inner 
workings that 3rd party backends don't.

Please take these comments as observations, not complaints.  I understand 
project evolution and the resistance to change something that doesn't seem 
broken.  Maybe keep some of these thoughts in mind when a change is made to 
the core backends or the compiler and consider how other backends will need 
to implement that new feature.

Scott
On Saturday, January 23, 2021 at 10:36:38 AM UTC-5 f.apo...@gmail.com wrote:

> On Saturday, January 23, 2021 at 12:41:35 AM UTC+1 t...@tomforb.es wrote:
>
>> > Honestly, I don't think we'd release this as a third party package.  We 
>> have had to code around a lot of core db specific code to get Snow SQL to 
>> work
>>
>> This is good feedback that is valuable for us to hear. Even if you don’t 
>> release it as a fully maintained package just understanding the pain points 
>> you encountered while developing this is great feedback that can help us 
>> improve.
>>
>> Would you be willing to share specific code snippets here, or just 
>> general areas that you found challenging while developing this backend?
>>
>
> +1, if it were possible to show the full code (even if you are not going 
> to maintain it in the longrun) would be very much helpful to improve.
>
> Like Tim I wrote one or two database backends in the past (informix and 
> the likes) and it was not to bad. That said, mine where relatively easy to 
> implement due to their closeness to existing database and (somehwat) 
> conformance with SQL standards. I'd love to see the code for snowflake and 
> maybe we can identify a few areas that would need improvement.
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/768b428d-8d7d-462a-b925-484a6e681b2bn%40googlegroups.com.

Re: Update returning

[charettes]

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 support for 
this feature while maintaining backward compability. Something along the 
lines of

def update(updates=None, *, returning=None, **kwargs):
if updates and kwargs:
raise TypeError('updates must be either specified through the first 
positional argument or kwargs')
if updates is None:
updates = kwargs
...

I guess we could force the usage of positional `updates` if `returning` is 
specified to prevent any silent breakages as well.

The usage of `returning` bring another set of questions though. Since 
UPDATE are not ordered RETURNING data has little value without the primary 
key associated with the updated rows. Maybe the return value of 
`returning=[f1, ..., fn]` should be a dict mapping the primary key to list 
of returning values.

e.g.

Post.objects.create(id=1, score=41)
Post.objects.update({"score": F("score") + 1}, returning=["score"])
-> {1: [42]}

Cheers,
Simon

Le mardi 26 janvier 2021 à 12:36:10 UTC-5, f.apo...@gmail.com a écrit :

> 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's 
>> not lazy in any way. It could be done in the other order like 
>> `QuerySet.objects.values("id", "name").update(name="Rob")` but I don't see 
>> the necessity to define "returning" fields in a chainable manner.
>>
>
> Ha, not sure what I was thinking. The sentence below I noted that update() 
> would return something but I didn't think that this would break chaining. 
> My bad.
>
> I looked further around and `get_or_create` has the nice workaround of 
> being able to use `defaults__exact` if it clashes with the `defaults` 
> keyword. Sadly we do not have that option here. Truth to be told I do not 
> think that many people have fields called returning
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86210b9b-4978-4068-ac61-f1a3061bf2a4n%40googlegroups.com.