Re: #21978 include production-ready web server

[Peter Baumgartner]

I put together a first stab at this at
https://github.com/lincolnloop/django-production. Feedback is appreciated!

On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com 
wrote:

> I hadn't seen django-simple-deploy. At first glance, it looks interesting,
> but more platform-specific than what I was thinking.
>
> I'll play around with creating a third-party app that encapsulates some of
> these thoughts and see where I end up.
>
> Thanks for your time and feedback!
>
> On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6 carlton...@gmail.com
> wrote:
>
>> Hey Pete.
>>
>> Yes, there can be a lot of steps... (and trouble is every one has a
>> different opinion once you get to specifics :)
>>
>> django-webserver looks good — in a similar ballpark to what I had in
>> mind, yes, but I'd probably not want to bundle the options for each server
>> myself, as that seems a lot to maintain over time... (Better to outsource
>> to the individual projects no?)
>>
>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>
>> https://github.com/ehmatthes/django-simple-deploy
>>
>> I really like the idea: in an opinionated way, it applies the project
>> changes you need to deploy (and it's plugable so folks could provide a
>> *template* for their own flavour of deployment if they wanted, which is
>> kind of important given the number of options in the landscape, even if you
>> only to *ship* a beginner option.)
>>
>> Tim Allen also recently raised improving the Django project template,
>> which I think is related here. (That's on my list too: async this QTR, then
>> hoping to take on Adam's proposal to modernise the Request object for the
>> end of year, then 🤞 swinging back here for "OK, what does it look like,
>> what can we do?" after that: there's a bunch of related tickets around
>> #21978 that it would be very sweet if we could clear up...)
>>
>> I think all these thoughts are really pursuable outside of core in the
>> very short run, even if the goal is to merge them — it's much easier to
>> experiment that way, and then say, "This worked".
>>
>> Anyhow, other than a "I've been thinking along these lines", and a
>> generally positive emote, I don't have too much more concrete at this
>> stage.
>> 👍
>> C.
>>
>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>> wrote:
>>
>>> Thanks for the additional background Carlton! I like the idea of
>>> having some sort of protocol that folks can follow to make
>>> ready-to-use Django server packages (django-webserver [1] is in the
>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>> great, but getting to production with that approach can feel like
>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>> dj-database-url, etc. and it ends up being a laundry list of things
>>> that, in my experience, people rarely get right on the first try and
>>> just result in frustration.
>>>
>>> It seems like part of the challenge here is reaching parity with the
>>> current runserver command, but is that necessary? Running `runserver
>>> --dev` locally and getting dev features like autoreloading and then
>>> having `runserver` use a different server for a deployed app doesn't
>>> seem unreasonable.
>>>
>>> [1] https://github.com/lincolnloop/django-webserver
>>>
>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>  wrote:
>>> >
>>> > Hey Pete.
>>> >
>>> > Yes... this is a good one.
>>> >
>>> > It's difficult to see how we can even have an ASGI runserver in core,
>>> simply because there's no SimpleServer equivalent as there is for WSGI, and
>>> it's not clear one is on the card. (HTTP is getting **more** complex, and I
>>> can't see  Python bringing such into the standard library.)
>>> > So we have to use a third-party dependency for that.
>>> >
>>> > For the Channels v4 update (in progress now) I'm moving the runserver
>>> command to the Daphne package. This was because folks wanted to use
>>> Channels without the Daphne/Twisted dependency.
>>> >
>>> > See: https://github.com/django/daphne/pull/429
>>> >
>>> > tl;dr — it came out pretty clean TBH. You pip install daphne, then add
>>> "daphne" at the top of INSTALLED_APPS. (There's a system check to make sure
>>> you're not fighting staticfiles.)
>>> >
>>> > On the back of that I don't see why servers (any servers) can't
>>> provide a runserver command (or a django-* mini-package to go with it) and
>>> offer what they offer in development as well as production. (Obviously that
>>> all needs writing but it's just a management command.)
>>> >
>>> > Related is strategising the reloader.
>>> https://code.djangoproject.com/ticket/30213
>>> >
>>> > We could then host *Protocols* — "Your runserver should do this",
>>> "Implement this for your reloader", and so on — and (maybe) (slowly)
>>> replace built-in options here with either optional dependencies (pip
>>> install django["daphne"]) or recommendations to get going. (pip install
>>> django["starter"] maybe). — I don't know — we seem a long w

Re: Proposal: Add An in-memory data storage backend in Django

[Paolo Melchiorre]

Yes, exactly.

Paolo

On Fri, Oct 21, 2022, 10:59 Joshua Thomas  wrote:

> Not to speak for Paulo, but I believe he meant using in-memory storage as
> a file storage backend, not data/database backend.
>
> On Thursday, October 20, 2022 at 4:50:49 PM UTC-7 shang.xia...@gmail.com
> wrote:
>
>> Hi,
>>
>> I may be missing some context here but is this something distinctly
>> different from setting SQLite to use in-memory storage [1]? 🤔
>>
>> [1] https://www.sqlite.org/inmemorydb.html
>>
>> David
>>
>> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
>> pa...@melchiorre.org> wrote:
>>
>>> Hi all,
>>>
>>> there is a package that provide in-memory data storage backend, but it's
>>> now abandoned.
>>>
>>> Having support for in-memory data storage could be very useful for
>>> Django itself and furthermore it would involve adding a small code with
>>> tests that do not justify the creation of a fork of that old package.
>>>
>>> We are talking about this during the sprints at DjangoCon US 2023 in San
>>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on
>>> this list.
>>>
>>> What do you think about adding an in-memory data storage backend
>>> directly in the Django core?
>>>
>>> Ciao,
>>> Paolo
>>>
>>> --
>>>
>> 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/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.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/2fe8f558-da42-4510-a8fa-344627652129n%40googlegroups.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/CAKFO%2Bx7W8vgVYDNiG%2B8j3q1kP2%2BEuf9ffwAk7fQXZ%2BWWX_rJsQ%40mail.gmail.com.

Adding relevant field name information to django.core.serializers.base.DeserializationError for importing fixtures Inbox

[logicOnAbstractions]

Hey,

When we import fixtures and the input data is wrong (ValueError), we get 
something along the following lines. Say the field is supposed to be an int 
and contains instead an empty string as opposed to null/None:
















*ErrorTraceback (most recent call last):  File 
"/run/media/venv/lib/python3.10/site-packages/django/db/models/fields/__init__.py",
 
line 1787, in to_pythonreturn int(value)ValueError: invalid literal for 
int() with base 10: ''During handling of the above exception, another 
exception occurred:Traceback (most recent call last):  File 
"/run/media/fv/hdd-2/GIT/VOLTEC-WEBAPP/app/venv/lib/python3.10/site-packages/django/core/serializers/python.py",
 
line 142, in Deserializerdata[field.name ] = 
field.to_python(field_value)  File 
"/run/media/fv/hdd-2/GIT/VOLTEC-WEBAPP/app/venv/lib/python3.10/site-packages/django/db/models/fields/__init__.py",
 
line 1789, in to_pythonraise 
exceptions.ValidationError(django.core.exceptions.ValidationError: ['“” 
value must be an integer.']During handling of the above exception, another 
exception occurred: (... more similar output...)*

This is raised for instance in 
*venv/lib/python3.10/site-packages/django/core/serializers/python.py 
*line 142 (and similarly in lines above of the same method):




*try:data[field.name 
] = field.to_python(field_value)except 
Exception as e:raise 
base.DeserializationError.WithData(e, d['model'], d.get('pk'), field_value)*

So we ultimately raise this exception:










*class DeserializationError(Exception):"""Something bad happened during 
deserialization."""@classmethoddef WithData(cls, original_exc, 
model, fk, field_value):"""Factory method for creating a 
deserialization error which has a moreexplanatory message.
"""return cls("%s: (%s:pk=%s) field_value was '%s'" % 
(original_exc, model, fk, field_value))*

At least up to the point where the exception is raised (in 
/serializers/python.py), we know which field exactly caused the error. 
However, in the final error outputs, that information isn't logged 
anywhere. How hard/easy would it be to either:
1 - Pass that info along to the WithData exception so that it can log it 
properly and yield that useful debugging info
2 - create a new custom exception, which would log the fieldname info, in 
case modifying WithData isn't easy/possible (for instance raised in other 
context where fieldname wouldn't be available)?

Thanks,

Franck


-- 
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/ecbbbdb5-6b40-4b0d-ae89-28cd042989ean%40googlegroups.com.

Re: Proposal: Add An in-memory data storage backend in Django

[Joshua Thomas]

Not to speak for Paulo, but I believe he meant using in-memory storage as a 
file storage backend, not data/database backend. 

On Thursday, October 20, 2022 at 4:50:49 PM UTC-7 shang.xia...@gmail.com 
wrote:

> Hi,
>
> I may be missing some context here but is this something distinctly 
> different from setting SQLite to use in-memory storage [1]? 🤔
>
> [1] https://www.sqlite.org/inmemorydb.html
>
> David
>
> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
> pa...@melchiorre.org> wrote:
>
>> Hi all,
>>
>> there is a package that provide in-memory data storage backend, but it's 
>> now abandoned.
>>
>> Having support for in-memory data storage could be very useful for Django 
>> itself and furthermore it would involve adding a small code with tests that 
>> do not justify the creation of a fork of that old package.
>>
>> We are talking about this during the sprints at DjangoCon US 2023 in San 
>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on 
>> this list.
>>
>> What do you think about adding an in-memory data storage backend directly 
>> in the Django core?
>>
>> Ciao,
>> Paolo
>>
>> -- 
>>
> 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/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.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/2fe8f558-da42-4510-a8fa-344627652129n%40googlegroups.com.

Changing the role of the Technical Board

[Andrew Godwin]

Hi everyone,

I want to start a conversation about the Technical Board and its role in 
Django, and how I'd like to change it, including its name.

Since its inception, the Technical Board has effectively only functioned as a 
backstop vote for large features that require DEPs, of which there have been 
only two in the last five years. I believe it can be much more useful than 
this, while still not dominating Django's direction.

I would like to initially suggest the following high-level changes, that I will 
start formalising into a process DEP if we reach broad agreement:

*Eligibility requirements are loosened and made less code-oriented*

Anyone who demonstrates a "decent" history of contributing to Django in any 
fashion, and who does not have any conflicts of interest, and clearly wants to 
work in the best interests of the framework, would be eligible. (Yes, this is 
going to be fun to define in a DEP).

The current eligibility requirements include the need to have participated in 
discussions about the direction or development of Django in the last two years, 
which given the relative lack of big discussions in the last two years makes it 
rather problematic.

*A more active role is taken in suggesting features*

A regular "call for big ideas" is taken by the Board, and a clear set of "these 
are the technical/design/process/etc. ideas that we'd like to do" is published. 
This list would be, among other things, useful to raise money for grants to 
work directly on those features.

DEP 10 already mostly provides for this - it says that the Board should "put 
out calls for proposals and ideas for the future technical direction of 
Django", so this would more be us just Doing The Thing rather than changing too 
many rules.

*The name is changed to "Steering Council"* (like Python)

I believe this is a more accurate reflection of what the group *should* be 
doing and a reflection that you should not need to be directly coding Django 
every day to participate - and names have meaning, and thus power.

*The overall election process, other powers, and current members remain the 
same*

I think this part works relatively well. I did consider if we should allow 
simultaneous Technical Board/Steering Council membership *and* DSF Board 
membership, as this is currently banned, but I think the reasons behind this 
still hold for now.

This of course would be a "major change" and trigger a lot of procedure, 
notably a supermajority vote of the current Board, and a DSF Board vote, but I 
do believe it is in the best interests of the framework.

I am very interested in any feedback on these suggested ideas, including any 
additional changes you think might be appropriate that I have not covered here.

Andrew

-- 
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/4d7a9a73-f231-4f01-93c9-59ba32b67a99%40app.fastmail.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

['Adam Johnson' via Django developers (Contributions to Django itself)]

I opened a ticket to add async methods to Model:
https://code.djangoproject.com/ticket/34112

This would be released in Django 4.2, at minimum.

Using async to perform model updates is not likely to be performant, since
the queries end up being processed synchronously on a thread anyway. This
is because the database libraries Django supports don't have async
interfaces.

On Fri, Oct 21, 2022 at 4:49 PM Adam Johnson  wrote:

> If you have a suggestion, sure. But from my perspective the docs are
> clear. There's an adelete() method doc'd for QuerySet, and not for Model,
> and the release note
> 
> says “QuerySet now provides an asynchronous interface...”.
>
> On Fri, Oct 21, 2022 at 3:51 PM Jason Johns  wrote:
>
>> gotcha, then perhaps a documentation tweak would be in order, on both
>> queryset and model pages?  because as is, its unclear this is expected.
>>
>> On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:
>>
>>> This is intentional, as it stands. Django 4.1 only added async QuerySet
>>> methods, not async Model methods. Async model methods like adelete(), and
>>> perhaps asave(), would be the next logical step.
>>>
>>> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>>>
 I came across a reddit post yesterday
 about
 `adelete` raising an attribute error

 r = await mymodel.objects.aget(some_name=myname)
 await r.adelete()

 would throw an `AttributeError`,

 whereas r = await mymodel.objects.filter(some_name=myname).adelete()
 works as expected.

 I was a little curious about this, and adelete
 
  is
 explicitly called out in the queryset docs within the `delete` section.
 but the models doc page
 only
 contains items about `delete`.  Is this intentional or not, and if it is
 intentional, perhaps a specific call-out in both queryset and model delete
 sections would help with clarification.

 --
 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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.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/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.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/CAMyDDM3H_JhAYwDhrFs5kpv8C8iq1eGBUbQ1hxOenpZ8rb%2BsqA%40mail.gmail.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

['Adam Johnson' via Django developers (Contributions to Django itself)]

If you have a suggestion, sure. But from my perspective the docs are clear.
There's an adelete() method doc'd for QuerySet, and not for Model, and
the release
note

says “QuerySet now provides an asynchronous interface...”.

On Fri, Oct 21, 2022 at 3:51 PM Jason Johns  wrote:

> gotcha, then perhaps a documentation tweak would be in order, on both
> queryset and model pages?  because as is, its unclear this is expected.
>
> On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:
>
>> This is intentional, as it stands. Django 4.1 only added async QuerySet
>> methods, not async Model methods. Async model methods like adelete(), and
>> perhaps asave(), would be the next logical step.
>>
>> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>>
>>> I came across a reddit post yesterday
>>> about
>>> `adelete` raising an attribute error
>>>
>>> r = await mymodel.objects.aget(some_name=myname)
>>> await r.adelete()
>>>
>>> would throw an `AttributeError`,
>>>
>>> whereas r = await mymodel.objects.filter(some_name=myname).adelete()
>>> works as expected.
>>>
>>> I was a little curious about this, and adelete
>>> 
>>>  is
>>> explicitly called out in the queryset docs within the `delete` section.
>>> but the models doc page
>>> only
>>> contains items about `delete`.  Is this intentional or not, and if it is
>>> intentional, perhaps a specific call-out in both queryset and model delete
>>> sections would help with clarification.
>>>
>>> --
>>> 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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.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/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.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/CAMyDDM2VVLGVW01ZcOHPeKk_KafOZ2uEXwjAgqSdjGQb0yBBcg%40mail.gmail.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

gotcha, then perhaps a documentation tweak would be in order, on both 
queryset and model pages?  because as is, its unclear this is expected.

On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:

> This is intentional, as it stands. Django 4.1 only added async QuerySet 
> methods, not async Model methods. Async model methods like adelete(), and 
> perhaps asave(), would be the next logical step.
>
> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>
>> I came across a reddit post yesterday 
>> about
>>  
>> `adelete` raising an attribute error
>>
>> r = await mymodel.objects.aget(some_name=myname) 
>> await r.adelete()
>>
>> would throw an `AttributeError`,
>>
>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() 
>> works as expected.
>>
>> I was a little curious about this, and adelete 
>> 
>>  is 
>> explicitly called out in the queryset docs within the `delete` section.  
>> but the models doc page  
>> only
>>  
>> contains items about `delete`.  Is this intentional or not, and if it is 
>> intentional, perhaps a specific call-out in both queryset and model delete 
>> sections would help with clarification.
>>
>> -- 
>> 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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.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/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

['Adam Johnson' via Django developers (Contributions to Django itself)]

This is intentional, as it stands. Django 4.1 only added async QuerySet
methods, not async Model methods. Async model methods like adelete(), and
perhaps asave(), would be the next logical step.

On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:

> I came across a reddit post yesterday
> about
> `adelete` raising an attribute error
>
> r = await mymodel.objects.aget(some_name=myname)
> await r.adelete()
>
> would throw an `AttributeError`,
>
> whereas r = await mymodel.objects.filter(some_name=myname).adelete() works
> as expected.
>
> I was a little curious about this, and adelete
> 
>  is
> explicitly called out in the queryset docs within the `delete` section.
> but the models doc page
> only
> contains items about `delete`.  Is this intentional or not, and if it is
> intentional, perhaps a specific call-out in both queryset and model delete
> sections would help with clarification.
>
> --
> 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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.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/CAMyDDM3L6gz0i9dp7S5xsmE8%2B7GCeY1L5A0h%2BQKxGv7zs6pu9w%40mail.gmail.com.

Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

I came across a reddit post yesterday 
about
 
`adelete` raising an attribute error

r = await mymodel.objects.aget(some_name=myname) 
await r.adelete()

would throw an `AttributeError`,

whereas r = await mymodel.objects.filter(some_name=myname).adelete() works 
as expected.

I was a little curious about this, and adelete 

 is 
explicitly called out in the queryset docs within the `delete` section.  
but the models doc page  
only
 
contains items about `delete`.  Is this intentional or not, and if it is 
intentional, perhaps a specific call-out in both queryset and model delete 
sections would help with clarification.

-- 
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/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com.