Re: get_manager short ut function proposal

[Ramez Ashraf]

Hello Adam
Happy new year!

Thank you for the feedback, really appreciate it.
I thought the same like you at first, a cool function in my project (which
is indeed the case)
One thing that gave me more incentive is the documentation code example.
IMO, i can see how shorter (and more readable) it would be with the
proposed shortcut.
In fact it's indeed simple and doesn't offer the full support a real
declared custom manager class would do. It's intended to be something like
get_object_or_404.

Interested or do you think the function can be enhanced it to make more
useable for your everyday other cases ?



On Sat, 31 Dec 2022, 12:41 'Adam Johnson' via Django developers
(Contributions to Django itself), 
wrote:

> Your proposal is quite niche: it only shortens the creation of a Manager
> class when you need to add a single filter() call. The function seems like
> it might be a useful helper within a project, if you use many such
> managers. But custom managers might use any queryset methods, or other
> logic. I've often used a custom manager to add annotate() and
> prefetch_related() calls.
>
> So, I think your shortcut is a smart addition for your project, but
> perhaps not suitable for Django itself. I think it's worth sharing in a
> blog post though!
>
> On Mon, Dec 19, 2022 at 10:51 PM Ramez Ashraf 
> wrote:
>
>> Hello everyone,
>>
>> I want to propose a helper function
>> `get_manager(parent_manager=None, *args, **kwargs)`
>>
>> A shortcut to return a manager, *args & **kwargs are passed to the
>> manager .filter()
>> pass parent_manager to customize the parent manager, defaults to
>> ``Manager``.
>>
>> it can be used like this
>>
>> from django.db.models import get_manager
>>
>> class Person(models.Model):
>> # ...
>> authors = models.get_manager(role='A')
>> editors = models.get_manager(role='E')
>> special = get_manager(~Q(name="Roald Dahl"), role='E')
>> manager_with_counts = get_manager(parent_manager=PollManager,
>> name="Roald Dahl")
>>
>> Instead of the current
>>
>> class AuthorManager(models.Manager):
>> def get_queryset(self):
>> return super().get_queryset().filter(role='A')
>>
>> class EditorManager(models.Manager):
>> def get_queryset(self):
>> return super().get_queryset().filter(role='E')
>>
>> class Person(models.Model):
>> people = models.Manager()
>> authors = AuthorManager()
>> editors = EditorManager()
>>...
>>
>> The first is more readable and nicer .. yeah ?
>> Code is working and ready at  github
>> 
>>  ,
>>
>> Do i get +1(s) to move forward and create a ticket ?
>>
>>
>> --
>> 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/f0e4367d-8a7e-48da-b78c-35036015212fn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/CISeAzzESHA/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAMyDDM0Jk%3DYsXQVRydaanmg%3DP_wMMmg%2B4uPETSvEXs3jFgCB%2BQ%40mail.gmail.com
> 
> .
>

-- 
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/CAPtjUth2XV-RajOfkj95C%2Bzy7tuQy%2B%3DzP8W5CMpxPB%2B9gkkpNg%40mail.gmail.com.

Re: Backport for ticket 34063?

[Shai Berger]

Hi,

I think at this point it would help to move the discussion forward, if
we tried to step beyond the specific issue and phrase the revision in
the backporting policy. This will let us, I hope, have a more
principle-based discussion.

If I get it right -- please correct me, James -- it would be something
like this addition:

"In a new domain of functionality, which is considered major and
central, bugs which would have been release blockers if found in time
will be considered as candidates for backporting if found within the
next two LTS versions" -- or even "... if found before use of the new
domain of functionality becomes mainstream" -- or something similar.

I think looking at it from that angle will be more fruitful. I will say
that looking at this principle, thinking about the vicious cycle
mentioned by James, I tend towards accepting his arguments.

We may want to phrase it a different way: Think of such major domains
as "experimental". We did that in the Python3 transition -- we had
"experimental support" from 1.5, and IIRC that "experimental" label
wasn't dropped until 1.8. I doubt we can retroactively declare async
views as still experimental, but we can modify the backporting policy
to say "release-blocker-level bugs in experimental features will be
candidates for backporting as long as the feature is experimental";
and we can set an exception that says "async is still experimental for
backporting considerations", in view of the little use we've seen so
far.

(I can see the argument against the last proposition, that says
"experimental means potentially broken, so it should be less worthy of
backports rather than more"; I disagree, because (a) we do want to
encourage such experimentation, and (b) no, it doesn't really mean
potentially broken, it means the API is not yet covered by the
stability guarantees; we're at more liberty to change things when we
fix)

HTH,
Shai.

-- 
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/20230101172133.29c41f34.shai%40platonix.com.

Re: get_manager short ut function proposal

[Shai Berger]

On Sun, 1 Jan 2023 16:33:45 +0200
Ramez Ashraf  wrote:

> 
> Interested or do you think the function can be enhanced it to make
> more useable for your everyday other cases ?
> 

This is half-baked, just a thought, but maybe you can take it some
place interesting:

Imagine a class that "collects" calls for later execution. Something
like (this exactly won't work, details below):

from functools import partialmethod
from django.db.models import QuerySet as QSet

class QS:
def __init__(self):
self._calls = []
def filter(self, *args, **kw):
self._calls.append(
partialmethod(QSet.filter, *args, **kw)
) 
return self
def annotate(*args, **kw):
# ... (same idea)
# ... other relevant methods, 
def __call__(self, qset):
for call in self._calls:
qset = apply(call, qset)
return qset

This won't work, I think, because partialmethod isn't supposed to work
quite this way, and the "apply" in the last line isn't defined. But
with this (fixed) already you could, I think, do something like

def qset_manager(qs: QS) -> Manager
class CustomManager(models.Manager):
def get_queryset(self):
orig = super().get_queryset()
return qs(orig)
return CustomManager()

And then, in your model, 

class Person(models.Model):
...
authors = qset_manager(QS().filter(role="A"))

and now the "make a manager with a modified queryset" pattern is
shortened in a general way.

As I said, just a half-baked thought. There's problems here to solve,
and many improvements to make.

HTH,
Shai.

-- 
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/20230101190053.671e8303.shai%40platonix.com.

Re: get_manager short ut function proposal

[Ramez Ashraf]

Mmmm I believe what you shared Shai is very sophisticated than what is
proposed.
The proposal is a shortcut function for with ability to have a custom
parent for more usability for an everyday use , like what's in the
documentation about managers.

My proposal is *not* a new way to write managers . This can be your or
someone else's fully baked idea.

With respect.

On Sun, 1 Jan 2023, 19:00 Shai Berger,  wrote:

> On Sun, 1 Jan 2023 16:33:45 +0200
> Ramez Ashraf  wrote:
>
> >
> > Interested or do you think the function can be enhanced it to make
> > more useable for your everyday other cases ?
> >
>
> This is half-baked, just a thought, but maybe you can take it some
> place interesting:
>
> Imagine a class that "collects" calls for later execution. Something
> like (this exactly won't work, details below):
>
> from functools import partialmethod
> from django.db.models import QuerySet as QSet
>
> class QS:
> def __init__(self):
> self._calls = []
> def filter(self, *args, **kw):
> self._calls.append(
> partialmethod(QSet.filter, *args, **kw)
> )
> return self
> def annotate(*args, **kw):
> # ... (same idea)
> # ... other relevant methods,
> def __call__(self, qset):
> for call in self._calls:
> qset = apply(call, qset)
> return qset
>
> This won't work, I think, because partialmethod isn't supposed to work
> quite this way, and the "apply" in the last line isn't defined. But
> with this (fixed) already you could, I think, do something like
>
> def qset_manager(qs: QS) -> Manager
> class CustomManager(models.Manager):
> def get_queryset(self):
> orig = super().get_queryset()
> return qs(orig)
> return CustomManager()
>
> And then, in your model,
>
> class Person(models.Model):
> ...
> authors = qset_manager(QS().filter(role="A"))
>
> and now the "make a manager with a modified queryset" pattern is
> shortened in a general way.
>
> As I said, just a half-baked thought. There's problems here to solve,
> and many improvements to make.
>
> HTH,
> Shai.
>

-- 
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/CAPtjUtg6JGLbdkcdTep-XbLVnogKg2EdJr%3DUJxP3Y0KRgmiaUA%40mail.gmail.com.

Re: Backport for ticket 34063?

[Tim Graham]

Older Django releases are currently maintained with minimal support that 
allows existing projects to continue running securely. I don't think we 
should invest resources in promoting them as a place to use experimental 
features. A benefit of running an old LTS release like 3.2 is that any 
release at this point is probably a very important upgrade (security or 
data loss issue). If we start making new LTS bug fix releases to fix 
experimental features, releases may be more frequent and less important. Of 
course, with more changes, the risk of unrelated regressions increases, 
including the possible bad situation in which users put off a bug fix 
upgrade because it doesn't have any security fixes only to face issues 
updating to a subsequent security release because of an issue in an interim 
bug fix release. (Maybe mergers can estimate how many other async fixes 
would be eligible for a backport based on the proposed criteria.)

James argues that this bug that went unreported for 2+ years is now very 
important and is going to cause massive pain for many users. Only time will 
answer this, but I'm skeptical. So far I believe we've seen two people 
affected, James and the ticket reporter.

This bug will be a non-issue for third-party apps with the release of 
Django 5.0 in December if they follow the suggested Django version support 
policy:

"Following the release of Django 5.0, we suggest that third-party app 
authors drop support for all versions of Django prior to 4.2. At that time, 
you should be able to run your package’s tests using python -Wd so that 
deprecation warnings appear. After making the deprecation warning fixes, 
your app should be compatible with Django 5.0."

Until then, apps could run the affected tests only on Django 4.2 (which 
will have an alpha release in about two weeks) if they don't want to work 
around the bug.
On Sunday, January 1, 2023 at 10:21:48 AM UTC-5 Shai Berger wrote:

> Hi,
>
> I think at this point it would help to move the discussion forward, if
> we tried to step beyond the specific issue and phrase the revision in
> the backporting policy. This will let us, I hope, have a more
> principle-based discussion.
>
> If I get it right -- please correct me, James -- it would be something
> like this addition:
>
> "In a new domain of functionality, which is considered major and
> central, bugs which would have been release blockers if found in time
> will be considered as candidates for backporting if found within the
> next two LTS versions" -- or even "... if found before use of the new
> domain of functionality becomes mainstream" -- or something similar.
>
> I think looking at it from that angle will be more fruitful. I will say
> that looking at this principle, thinking about the vicious cycle
> mentioned by James, I tend towards accepting his arguments.
>
> We may want to phrase it a different way: Think of such major domains
> as "experimental". We did that in the Python3 transition -- we had
> "experimental support" from 1.5, and IIRC that "experimental" label
> wasn't dropped until 1.8. I doubt we can retroactively declare async
> views as still experimental, but we can modify the backporting policy
> to say "release-blocker-level bugs in experimental features will be
> candidates for backporting as long as the feature is experimental";
> and we can set an exception that says "async is still experimental for
> backporting considerations", in view of the little use we've seen so
> far.
>
> (I can see the argument against the last proposition, that says
> "experimental means potentially broken, so it should be less worthy of
> backports rather than more"; I disagree, because (a) we do want to
> encourage such experimentation, and (b) no, it doesn't really mean
> potentially broken, it means the API is not yet covered by the
> stability guarantees; we're at more liberty to change things when we
> fix)
>
> HTH,
> Shai.
>

-- 
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/35bad7b0-1811-4a1e-a396-bd8e6591699fn%40googlegroups.com.

Apache and mod_wsgi

[pankaj palmate]

Hi i am using Apache with mod_wsgi.i want to serve 5000 users at a time.how
many processes and threads should I use in order to serve 5000 connections
concurrently...in wsgi daemon process ?

-- 
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/CAPyMU1LVzug7RAXR4TC52TEpUjWZeyAsTYyYavaDPK7yttNZRA%40mail.gmail.com.

Re: Apache and mod_wsgi

[Ferran Jovell]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Ferran

Missatge de pankaj palmate  del dia dg., 1 de
gen. 2023 a les 22:10:

> Hi i am using Apache with mod_wsgi.i want to serve 5000 users at a
> time.how many processes and threads should I use in order to serve 5000
> connections concurrently...in wsgi daemon process ?
>
> --
> 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/CAPyMU1LVzug7RAXR4TC52TEpUjWZeyAsTYyYavaDPK7yttNZRA%40mail.gmail.com
> 
> .
>

-- 
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/CAEKh-skrAqL2DLteyjYrdcKBRpfvbSiNmpdJZBJ3hRQNLSdQkg%40mail.gmail.com.

Re: Backport for ticket 34063?

[James Bennett]

On Sun, Jan 1, 2023 at 12:54 PM Tim Graham  wrote:
> Older Django releases are currently maintained with minimal support that 
> allows existing projects to continue running securely. I don't think we 
> should invest resources in promoting them as a place to use experimental 
> features. A benefit of running an old LTS release like 3.2 is that any 
> release at this point is probably a very important upgrade (security or data 
> loss issue). If we start making new LTS bug fix releases to fix experimental 
> features, releases may be more frequent and less important. Of course, with 
> more changes, the risk of unrelated regressions increases, including the 
> possible bad situation in which users put off a bug fix upgrade because it 
> doesn't have any security fixes only to face issues updating to a subsequent 
> security release because of an issue in an interim bug fix release. (Maybe 
> mergers can estimate how many other async fixes would be eligible for a 
> backport based on the proposed criteria.)

The backport policy already says that Django will backport certain
things into older releases. I do not agree with your assessment of the
risk of backporting, but even if we grant it for sake of argument, the
Django project overall has already clearly endorsed -- through the
current backport policy -- the idea that some fixes are important
enough to override such concerns and to backport even into releases
that are on "minimal" support.

I happen to think that this is one such fix, for reasons that I have
laid out at length. I also think the backport policy should be amended
to prevent an issue like this from "slipping through the cracks" again
in the future. I am still considering the wording Shai proposed,
though on first read I thought it was getting at the right idea.

> James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter.

Well.

I had been trying to avoid bringing this up because I felt that the
backport policy and the severity of the bug were the things to focus
on, and because I was trying to avoid singling out individual mistakes
that contributed to the situation we have now. But there is at least
one other report of this bug in the Django Trac instance. It is the
first one I found when trying to diagnose the problem in my own code
(and the one I mentioned in my initial question on IRC, as anyone who
saw that can confirm), and it is one that was filed only a couple of
months after the release of Django 3.1, so well within the window of
time when the backport policy would have said to apply the fix to the
3.1 branch as well as to main. It also correctly diagnosed the source
of the bug and provided an attempt at a patch.

That ticket was #32189:

https://code.djangoproject.com/ticket/32189

But it was closed invalid as a user error. We can debate whether the
user should have been trying to access request.POST for their
particular use case, but we cannot debate whether this is the
underlying bug that user was encountering. It also was clearly not the
normal behavior one ought to see from accessing request.POST, even in
a non-POST request or supposedly non-appropriate context, and likely
either should not have been closed, or should have produced a
follow-up ticket to investigate why that specific behavior was
occurring.

As for whether anyone else is affected: my searching turned up several
references on other sites to the exact error message the bug produces,
which all seemed to receive replies along the lines of #32189: that it
was the fault of the reporter for accessing request.POST rather than
request.body.

So. I have said several times that using a strict reading of the
backport policy to avoid fixing a severe bug sends a bad message. I
will amend that now, and say that using a strict reading of the
backport policy to avoid fixing a bug, when the bug was reported to
Django within a window where the backport policy should not have
mattered, sends an even worse message.

I also do think that more people will trip over this bug as they start
using async Django, and that leaving it unfixed creates a problem of
how to communicate the need for a workaround without violating a
strict reading of the backport policy.

> This bug will be a non-issue for third-party apps with the release of Django 
> 5.0 in December if they follow the suggested Django version support policy:

I have repeatedly pointed out that I do not think Django should force
the choice of long-delayed async adoption, or fracturing of the
community, onto maintainers of third-party packages and libraries. My
objection was to waiting until Django 3.2 drops out of support, which
is in April 2024, but the objection would apply equally to saying that
a feature released in 2020 must be left in a state where it is not
reliably 

Re: Backport for ticket 34063?

[Tim Graham]

I guess it's nice to have a strict backport policy, partly to avoid hours 
of discussion like this, which ultimately boils down to a 
judgment/prediction about severity and whether or not the current backport 
policy should be amended. If I encountered a similar issue, I would have 
just worked around it and moved on. Surely there are other issues like this 
one that don't meet the current backport criteria but that could be 
similarly argued by someone persistent enough. It would be nice if the 
outcome here avoided that in the future.

I guess there's not much to add on either side of the argument at this 
point. Perhaps the best solution is what Shai outlined: to propose amending 
the backport criteria, either by expanding the LTS backport categories 
beyond security and data loss issues, or by allowing the steering council 
to vote on backport proposals on a case-by-case basis, at least if there's 
no consensus on the mailing list.
On Sunday, January 1, 2023 at 5:41:03 PM UTC-5 James Bennett wrote:

> On Sun, Jan 1, 2023 at 12:54 PM Tim Graham  wrote:
> > Older Django releases are currently maintained with minimal support that 
> allows existing projects to continue running securely. I don't think we 
> should invest resources in promoting them as a place to use experimental 
> features. A benefit of running an old LTS release like 3.2 is that any 
> release at this point is probably a very important upgrade (security or 
> data loss issue). If we start making new LTS bug fix releases to fix 
> experimental features, releases may be more frequent and less important. Of 
> course, with more changes, the risk of unrelated regressions increases, 
> including the possible bad situation in which users put off a bug fix 
> upgrade because it doesn't have any security fixes only to face issues 
> updating to a subsequent security release because of an issue in an interim 
> bug fix release. (Maybe mergers can estimate how many other async fixes 
> would be eligible for a backport based on the proposed criteria.)
>
> The backport policy already says that Django will backport certain
> things into older releases. I do not agree with your assessment of the
> risk of backporting, but even if we grant it for sake of argument, the
> Django project overall has already clearly endorsed -- through the
> current backport policy -- the idea that some fixes are important
> enough to override such concerns and to backport even into releases
> that are on "minimal" support.
>
> I happen to think that this is one such fix, for reasons that I have
> laid out at length. I also think the backport policy should be amended
> to prevent an issue like this from "slipping through the cracks" again
> in the future. I am still considering the wording Shai proposed,
> though on first read I thought it was getting at the right idea.
>
> > James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter.
>
> Well.
>
> I had been trying to avoid bringing this up because I felt that the
> backport policy and the severity of the bug were the things to focus
> on, and because I was trying to avoid singling out individual mistakes
> that contributed to the situation we have now. But there is at least
> one other report of this bug in the Django Trac instance. It is the
> first one I found when trying to diagnose the problem in my own code
> (and the one I mentioned in my initial question on IRC, as anyone who
> saw that can confirm), and it is one that was filed only a couple of
> months after the release of Django 3.1, so well within the window of
> time when the backport policy would have said to apply the fix to the
> 3.1 branch as well as to main. It also correctly diagnosed the source
> of the bug and provided an attempt at a patch.
>
> That ticket was #32189:
>
> https://code.djangoproject.com/ticket/32189
>
> But it was closed invalid as a user error. We can debate whether the
> user should have been trying to access request.POST for their
> particular use case, but we cannot debate whether this is the
> underlying bug that user was encountering. It also was clearly not the
> normal behavior one ought to see from accessing request.POST, even in
> a non-POST request or supposedly non-appropriate context, and likely
> either should not have been closed, or should have produced a
> follow-up ticket to investigate why that specific behavior was
> occurring.
>
> As for whether anyone else is affected: my searching turned up several
> references on other sites to the exact error message the bug produces,
> which all seemed to receive replies along the lines of #32189: that it
> was the fault of the reporter for accessing request.POST rather than
> request.body.
>
> So. I have said several times that using a strict reading of the
> backport 

Re: Backport for ticket 34063?

[Tim Graham]

Incidentally, I don't think it's important for the ultimate decision here, 
but I looked at the below analysis of ticket #32189. Carlton's analysis on 
the ticket that request.POST is empty when using 'content-type': 
'application/json' remains true. The results of the tests provided in the 
description of #32189 remain unchanged by the fix for #34063 
(test_request_factory_data_multipart passes and 
test_request_factory_data_json fails in the same way as in the ticket 
description). I would triage #32189 exactly as Carlton did. I don't see 
anything in that ticket that leads to the "AssertionError: Cannot read more 
than the available bytes from the HTTP incoming data." as in #34063. It's 
possible I made a mistake or that my knowledge is lacking, but I see 
nothing that would make me mark #32189 as a duplicate of #34063 (which I 
was planning to correct for posterity if it's indeed the case). It's 
possible that reporter did encounter the "Cannot read..." AssertionError at 
some point, but I see nothing concrete in the ticket that reproduces it. I 
hope that's clarifying!


> > James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter. 
>
> Well. 
>
> I had been trying to avoid bringing this up because I felt that the 
> backport policy and the severity of the bug were the things to focus 
> on, and because I was trying to avoid singling out individual mistakes 
> that contributed to the situation we have now. But there is at least 
> one other report of this bug in the Django Trac instance. It is the 
> first one I found when trying to diagnose the problem in my own code 
> (and the one I mentioned in my initial question on IRC, as anyone who 
> saw that can confirm), and it is one that was filed only a couple of 
> months after the release of Django 3.1, so well within the window of 
> time when the backport policy would have said to apply the fix to the 
> 3.1 branch as well as to main. It also correctly diagnosed the source 
> of the bug and provided an attempt at a patch. 
>
> That ticket was #32189: 
>
> https://code.djangoproject.com/ticket/32189 
>
> But it was closed invalid as a user error. We can debate whether the 
> user should have been trying to access request.POST for their 
> particular use case, but we cannot debate whether this is the 
> underlying bug that user was encountering. It also was clearly not the 
> normal behavior one ought to see from accessing request.POST, even in 
> a non-POST request or supposedly non-appropriate context, and likely 
> either should not have been closed, or should have produced a 
> follow-up ticket to investigate why that specific behavior was 
> occurring. 
>

-- 
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/05fef0dd-e608-46d2-a850-ddc5574183c2n%40googlegroups.com.

Re: Generated Field

[Jeremy Nauta]

I have implemented a first draft for this feature! Feedback and ideas are 
greatly appreciated.

https://github.com/django/django/pull/16417
https://code.djangoproject.com/ticket/34238

On Saturday, December 24, 2022 at 8:56:38 p.m. UTC-7 schinckel wrote:

> I believe there are a bunch of similarities between the requirements of 
> generated fields and my project django-shared-property: 
> https://django-shared-property.readthedocs.io/en/latest/
>
> On Sunday, December 25, 2022 at 10:23:10 AM UTC+10:30 jeremy...@gmail.com 
> wrote:
>
>> I'd love to help implement this if we can find a rough syntax! I've made 
>> a proof of concept in Postgres, and there are two outstanding limitations 
>> to address:
>>
>> - The generated field value is not set until the model is reloaded from 
>> the database
>> - The `GENERATED ALWAYS` expression requires an argument to be injected 
>> in the the sql expression, but this is not currently possible
>>
>> *from django.db.backends.utils import CursorWrapper*
>>
>> *from django.db.models import Expression, Field*
>>
>> *from django.db.models.sql import Query*
>>
>>
>>
>> *class GeneratedField(Field):*
>>
>> *"""*
>>
>> *Wrapper field used to support generated columns in postgres.*
>>
>> *"""*
>>
>>
>> *def __init__(self, expression: Expression, db_collation: str = None, 
>> *args, **kwargs):*
>>
>> *"""*
>>
>> *:param expression: DB expression used to calculate the 
>> auto-generated field value*
>>
>> *"""*
>>
>>
>> *self.expression = expression*
>>
>> *self.db_collation = db_collation*
>>
>>
>> *kwargs['editable'] = False  # This field can never be edited*
>>
>> *kwargs['blank'] = True  # This field never requires a value to 
>> be set*
>>
>> *kwargs['null'] = True  # This field never requires a value to be 
>> set*
>>
>>
>> *super().__init__(*args, **kwargs)*
>>
>>
>> *def _compile_expression(self, cursor: CursorWrapper, sql: str, 
>> params: dict):*
>>
>> *"""*
>>
>> *Compiles SQL and its associated parameters into a full SQL 
>> query. Usually sql params are kept*
>>
>> *separate until `cursor.execute()` is called, but this is not 
>> possible since this function*
>>
>> *must return a single sql string.*
>>
>> *"""*
>>
>>
>> *return cursor.mogrify(sql, params).decode()*
>>
>>
>> *def db_type(self, connection):*
>>
>> *"""*
>>
>> *Called when calculating SQL to create DB column (e.g. DB 
>> migrations)*
>>
>> *
>> https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.db_type
>>  
>> *
>>
>> *"""*
>>
>>
>> *db_type = 
>> self.expression.output_field.db_type(connection=connection)*
>>
>>
>> *# Convert any F() references to concrete field names*
>>
>> *query = Query(model=self.model, alias_cols=False)*
>>
>> *expression = self.expression.resolve_expression(query, 
>> allow_joins=False)*
>>
>>
>> *# Compile expression into SQL*
>>
>> *expression_sql, params = expression.as_sql(*
>>
>> *compiler=connection.ops.compiler('SQLCompiler')(*
>>
>> *query, connection=connection, using=None*
>>
>> *),*
>>
>> *connection=connection,*
>>
>> *)*
>>
>>
>> *with connection.cursor() as cursor:*
>>
>> *expression_sql = self._compile_expression(*
>>
>> *cursor=cursor, sql=expression_sql, params=params*
>>
>> *)*
>>
>>
>> *return f'{db_type} GENERATED ALWAYS AS ({expression_sql}) 
>> STORED'*
>>
>>
>> *def rel_db_type(self, connection):*
>>
>> *"""*
>>
>> *Called when calculating SQL to reference DB column*
>>
>> *
>> https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.rel_db_type
>>  
>> *
>>
>> *"""*
>>
>> *return 
>> self.expression.output_field.db_type(connection=connection)*
>>
>>
>> *def deconstruct(self):*
>>
>> *"""*
>>
>> *Add custom field properties to allow migrations to deconstruct 
>> field*
>>
>> *
>> https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.deconstruct
>>  
>> *
>>
>> *"""*
>>
>> *name, path, args, kwargs = super().deconstruct()*
>>
>> *kwargs['expression'] = self.expression*
>>
>> *if self.db_collation is not None:*
>>
>> *kwargs['db_collation'] = self.db_collation*
>>
>> *return name, path, args, kwargs*
>>
>>
>>
>> *class GeneratedFieldQuerysetMixin:*
>>
>> *"""*
>>
>> *Must be added to queryset classes*
>>
>> *"""*
>>
>>
>> *def _insert(self, 

Re: Backport for ticket 34063?

[James Bennett]

On Sun, Jan 1, 2023 at 7:01 PM Tim Graham  wrote:
> Incidentally, I don't think it's important for the ultimate decision here, 
> but I looked at the below analysis of ticket #32189. Carlton's analysis on 
> the ticket that request.POST is empty when using 'content-type': 
> 'application/json' remains true.

The bug report specifically says:

> First due to the limitation in reading from FakePayload, in the real world 
> you can ask to read more just you would not read more i think
> I found http request was setting a high chunk size for an unrelated test and 
> failing to read from fake payload
>
> Then i notice that when trying to use a content type json not multipart 
> (default) that the post data was empty again!
> This time it seemed to be due to handling of application / json content

I read that as clearly saying that the reporter's earlier attempt(s)
*did* encounter the same bug as #34063, since otherwise why mention
the read/chunk size and the mechanics of reading from FakePayload? It
seems like a later attempt ran into the separate issue of the
application/json content type not populating request.POST. Ideally
this bug report would have been followed up with a "wait, why did it
hit that code path with the read size error" during triage, since that
is *not* what ought to be happening, even when request.POST is
inappropriately accessed on a non-form request (request.POST should
just be an empty QueryDict in that case).

So I do believe #32189 is a duplicate of #34063. It just happened that
the reporter had hit multiple issues: one was user error, but the
other was a genuine bug in Django.

> If I encountered a similar issue, I would have just worked around it and 
> moved on. Surely there are other issues like this one that don't meet the 
> current backport criteria but that could be similarly argued by someone 
> persistent enough. It would be nice if the outcome here avoided that in the 
> future.

As I keep saying: for a feature as hyped up as async, and for a bug of
this severity in the async testing support, I do not think Django can
afford such a lackadaisical "work around it yourself" policy without
incurring significant reputational harm. Nor can the response be that
people should just upgrade -- mostly because Django should have fixed
this bug two years ago, but even today Django should take
responsibility for the bug and provide a backport of the fix into all
the supported releases. And especially should do so since it *still*
is not possible, today, to "upgrade" to a released version of Django
containing the fix.

> I guess it's nice to have a strict backport policy, partly to avoid hours of 
> discussion like this

The fix could have been backported and released a dozen times over,
and the backport policy amended with language to explicitly allow
fixes like this one but not open the floodgates to anything and
everything, in the amount of time that has been devoted to trying to
prevent this from being backported.

At any rate, your remaining objections basically seem to boil down to
not liking the time and effort being spent on this. I have already
offered to do whatever work is needed to see the backports through to
release. It is not a particularly difficult patch, so far as I can
tell, and I have significant direct experience backporting and
maintaining much gnarlier bugfixes in branches of Django. So the
time/effort objection is moot.

-- 
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/CAL13Cg_yTXKx7GRYuzqhiUZ%3Dy%3DbJesD%3D9TGjrjei6a_4D0SLfQ%40mail.gmail.com.

Django bugfix release: 4.1.5

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2023/jan/02/bugfix-release/

--
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/8ac3a04d-5545-b92a-82c4-7abd647bde6b%40gmail.com.