Re: select quantity for each items selected in many to many field

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for 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. Read more on the mailing
lists at https://www.djangoproject.com/community/

I've had a quick read of your question, but I'm afraid I don't quite follow
your data model enough to answer it right now.

For support, please use the django-users mailing list, or IRC #django on
Freenode, or a site like Stack Overflow. There are people out there willing
to help on those channels, but they might not respond if you don't ask your
question well. Stack Overflow's question guide can help you frame it well:
https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Fri, 19 Jul 2019 at 20:26, hunar techie 
wrote:

> hi there i'm working on an restaurant ordering system , when someone order
> more than one product with different quantities for each product , be able
> to select its quantities
> it may order 3 Pizza with 2 sandwich , how to let the customer to define
> the quantities of each product , and then calculate with its prices
>  class Restaurant(models.Model):
>
> name = models.CharField(max_length=50)
> price = models.PositiveIntegerField(default=1)
>
>
> def __str__(self):
> return self.name
> class Topping(models.Model):
> name = models.CharField(max_length=50)
> product_names = models.ManyToManyField(Restaurant, blank=True)
> quantity = models.PositiveIntegerField(default=1)
>
>
> total price of orders , for one product for example : one pizza with one 
> sandwich however they order more than one pizza and sandwich
>
> @property
> def total(self):
> return self.product_names.aggregate(Sum('price'))['price__sum']
>
> I expected to provide a quantity field for each selected items : pizza : 3
> , sandwich:2 , then calculate them (3*pizza price , 2*sandwich price)
>
> thanks for advice
>
>
> --
> 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/CAKJtO%2Bt3BPPr6m4jkeU0qPR00p5Aoun1h%2Bw7mi%2BYi5jqNf4WoQ%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/CAMyDDM0kNcbS8oPC8f%3D9ztkG5zkGiPKMi%3DNN9H0ZB17uVqxrhA%40mail.gmail.com.

Re: Discuss https://github.com/django/django/pull/11157

[Petr Glotov]

Overriding render_to_response() would take creating an instance of 
StreamingHttpResponse with streaming_content kwarg using 
self.resolve_template(), self.resolve_content() and applying 
self.make_bytes() to it? It's possible but as a user i'd rather not need to 
know how Django's TemplateView operates under the hood. It's like if an 
automaker coming up with a new engine but refusing to make a car with it 
and instead selling the engine itself suggesting people to build cars 
themselves.
Still, what if we implement TemplateView(stream=True)which would do it 
internally? We don't have to expose StreamingTemplateResponse.



On Saturday, July 20, 2019 at 5:22:37 AM UTC-7, Carlton Gibson wrote:
>
> I’m exactly -1 on this, for exactly the reasons given.   ALL it takes for 
> you to implement this is to subclass TemplateView and override 
> render_to_response(). That’s it. 
>
> This was Tom’s point in his review four years ago: the ease of directly 
> implementing it means the added API surface area isn’t worth it. 
>
> On Sat, 20 Jul 2019 at 13:31, Petr Glotov > 
> wrote:
>
>> What if we keep  *StreamingTemplateResponse* and do 
>> *TemplateView(stream=True) 
>> *flag?
>> I just want to have something out of the box to use.
>>
>>
>> On Friday, July 19, 2019 at 5:40:52 PM UTC-7, Petr Glotov wrote:
>>>
>>> Hi All, there is a PR  where 
>>> template streaming is introduced, and recently a discussion emerged on 
>>> wether a *StreamingTemplateView* class belongs in Django. I know for 
>>> sure I'd be glad to replace *TemlateView *based views in one of project 
>>> I'm working on with the proposed *StreamingTemplateView *and be done 
>>> with it. The alternative point of view is that it would take a user an 
>>> extra step of making a decision ("decision point") of (i guess) choosing 
>>> between *TemplateView* and *StreamingTemplateView*, so the suggestion 
>>> is to remove *StreamingTemplateView*. So I would like to ask people to 
>>> chime in. Thanks!
>>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/86877d7b-94ba-4ab7-9bcc-e2f39eab8578%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/1d962796-092c-41c7-8766-bcf21b7cfe7f%40googlegroups.com.

Re: Django Async DEP

[Andrew Godwin]

Hi everyone,

After a long and involved vote, I can announce that the Technical Board has
voted in favour of DEP 0009 (Async Django), and so the DEP has been moved
to the "accepted" state.

As some may have seen, I've started work on adding async support to views (
https://github.com/django/django/compare/master...andrewgodwin:async_views)
- this is, as the DEP states, the last "blocking" change before we can open
up lots of parallel work on making other parts of Django async, and so now
the DEP is approved the next step is to work out funding and organisation
for future async work.

If you are interested in helping with fundraising, then please get in touch
with me directly; I have some ideas about how to structure it, but I could
do with some people to help out. Otherwise, stay tuned for more information
about how to get involved contributing and what to work on!

Andrew

On Sat, Jun 8, 2019 at 9:14 AM Andrew Godwin  wrote:

>
>
> On Sat, Jun 8, 2019 at 3:14 AM Pascal Chambon 
> wrote:
>
>> Hello,
>>
>> There is something a little scary for me, in changing all the core of
>> Django to async, when this really helps only, imho, a tiny fraction of
>> users : websocket/long polling services, and reddit-like sites with
>> thousands+ hits per second. For most webpages and webservices, async
>> artillery sounds quite overkill.
>>
>> Are cpython threads inefficient ? As far as I know they are only kernel
>> threads constrained by the Gil, so they shouldnt wake up when they are
>> blocked on io syscalls/mutexes (or do they?), and context switches remain
>> acceptable compared to the slowness of python itself.
>>
>
> It's fine when you only at 5/10 threads - which, notably, is what most
> WSGI servers run at. When you get to the hundreds, though, you start losing
> a large proportion of your execution time (tens of percent, in some cases).
>
>
>>
>> We used to provide provisioning and automatic authentication for 20
>> million users, with partner webservices tar-pitting us for sometimes 1mn.
>> The nightmare scenario. But with 2 machines, 1 process by core, and 800
>> threads by process, it did the job, enough for us to answer millions of
>> hits a day. Without even relying on other no-recoding optimizations like
>> pypy or gevent.
>>
>> Async would certainly have been a relevant techno if we had known in
>> advance that our partners would be so slow, but avoiding the extra
>> complexity burden of this style (where a single buggy dependency can block
>> all requests in a process, where all modules have to be recoded for it) was
>> also a huge benefit. And the limited thread pool also protected our DB from
>> unbearable loads.
>>
>
> Please remember that even after this change, Django will still expect you
> to write synchronously by default, and not impose any of that extra
> complexity on you. We will only swap out the "native" implementation of
> things if the performance matches (within ~10%) or exceeds that of the
> synchronous version when there's a couple of threads going; it's expected
> this will largely be the case due to the direct benefits of idling less.
>
> But - the plan is not to make it more complex by default (you only have to
> interact with the async if you want to) or slower.
>
>
>>
>> It's very nice if a proper async ecosystem emerges in python, but I fear
>> lots of people are currently jumping into it without a need for such
>> performance, and at the expense of lots of much more important matters like
>> robust ess, correctness, compatibility... like it happened for docker and
>> microservices, transforming into fragile bloatwares simple intranets, which
>> just needed a single django codebase deployed in a single container.
>>
>> A few days ago I audited a well used django module, the current user was
>> stored in a global variable (!!!). People might eventually fix that ticket,
>> use threadlocals, and then switch to a future django-async without
>> realizing that the security issue has come back due to the way async works.
>>
>> Still I hope I'm wrong, that the performance gains will prove worth the
>> software fragmentation and complexity brought by asyncio, but I still dont
>> understand them for 99% users... Especially as long as key-in-hand
>> solutions like greenlets exist for power users.
>>
>>
> I agree with you that there's a chance this is all useless and doesn't
> bear fruit, in which case I will be the first person to pull the plug and
> say that Python async isn't ready. However, I've been working with it for
> the last four years, including on several very large deployments, and there
> are some direct benefits that I believe we can get without making things a
> lot more complex, even inside Django.
>
> 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

Re: Django Async DEP

[Jacob Kaplan-Moss]

Congratulations, and great news!

I hope the TB will consider sharing details and/or a summary of the "long
and involved vote"; I'll bet there's a bunch the broader community could
learn from the specifics.

Jacob

On Sun, Jul 21, 2019 at 3:54 PM Andrew Godwin  wrote:

> Hi everyone,
>
> After a long and involved vote, I can announce that the Technical Board
> has voted in favour of DEP 0009 (Async Django), and so the DEP has been
> moved to the "accepted" state.
>
> As some may have seen, I've started work on adding async support to views (
> https://github.com/django/django/compare/master...andrewgodwin:async_views)
> - this is, as the DEP states, the last "blocking" change before we can open
> up lots of parallel work on making other parts of Django async, and so now
> the DEP is approved the next step is to work out funding and organisation
> for future async work.
>
> If you are interested in helping with fundraising, then please get in
> touch with me directly; I have some ideas about how to structure it, but I
> could do with some people to help out. Otherwise, stay tuned for more
> information about how to get involved contributing and what to work on!
>
> Andrew
>
> On Sat, Jun 8, 2019 at 9:14 AM Andrew Godwin  wrote:
>
>>
>>
>> On Sat, Jun 8, 2019 at 3:14 AM Pascal Chambon 
>> wrote:
>>
>>> Hello,
>>>
>>> There is something a little scary for me, in changing all the core of
>>> Django to async, when this really helps only, imho, a tiny fraction of
>>> users : websocket/long polling services, and reddit-like sites with
>>> thousands+ hits per second. For most webpages and webservices, async
>>> artillery sounds quite overkill.
>>>
>>> Are cpython threads inefficient ? As far as I know they are only kernel
>>> threads constrained by the Gil, so they shouldnt wake up when they are
>>> blocked on io syscalls/mutexes (or do they?), and context switches remain
>>> acceptable compared to the slowness of python itself.
>>>
>>
>> It's fine when you only at 5/10 threads - which, notably, is what most
>> WSGI servers run at. When you get to the hundreds, though, you start losing
>> a large proportion of your execution time (tens of percent, in some cases).
>>
>>
>>>
>>> We used to provide provisioning and automatic authentication for 20
>>> million users, with partner webservices tar-pitting us for sometimes 1mn.
>>> The nightmare scenario. But with 2 machines, 1 process by core, and 800
>>> threads by process, it did the job, enough for us to answer millions of
>>> hits a day. Without even relying on other no-recoding optimizations like
>>> pypy or gevent.
>>>
>>> Async would certainly have been a relevant techno if we had known in
>>> advance that our partners would be so slow, but avoiding the extra
>>> complexity burden of this style (where a single buggy dependency can block
>>> all requests in a process, where all modules have to be recoded for it) was
>>> also a huge benefit. And the limited thread pool also protected our DB from
>>> unbearable loads.
>>>
>>
>> Please remember that even after this change, Django will still expect you
>> to write synchronously by default, and not impose any of that extra
>> complexity on you. We will only swap out the "native" implementation of
>> things if the performance matches (within ~10%) or exceeds that of the
>> synchronous version when there's a couple of threads going; it's expected
>> this will largely be the case due to the direct benefits of idling less.
>>
>> But - the plan is not to make it more complex by default (you only have
>> to interact with the async if you want to) or slower.
>>
>>
>>>
>>> It's very nice if a proper async ecosystem emerges in python, but I fear
>>> lots of people are currently jumping into it without a need for such
>>> performance, and at the expense of lots of much more important matters like
>>> robust ess, correctness, compatibility... like it happened for docker and
>>> microservices, transforming into fragile bloatwares simple intranets, which
>>> just needed a single django codebase deployed in a single container.
>>>
>>> A few days ago I audited a well used django module, the current user was
>>> stored in a global variable (!!!). People might eventually fix that ticket,
>>> use threadlocals, and then switch to a future django-async without
>>> realizing that the security issue has come back due to the way async works.
>>>
>>> Still I hope I'm wrong, that the performance gains will prove worth the
>>> software fragmentation and complexity brought by asyncio, but I still dont
>>> understand them for 99% users... Especially as long as key-in-hand
>>> solutions like greenlets exist for power users.
>>>
>>>
>> I agree with you that there's a chance this is all useless and doesn't
>> bear fruit, in which case I will be the first person to pull the plug and
>> say that Python async isn't ready. However, I've been working with it for
>> the last four years, including on several very large deployments, and there
>> are some dir

Re: Django Async DEP

[Andrew Godwin]

I'll ask permission and then summarise the points raised back out here!

Andrew

On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss 
wrote:

> Congratulations, and great news!
>
> I hope the TB will consider sharing details and/or a summary of the "long
> and involved vote"; I'll bet there's a bunch the broader community could
> learn from the specifics.
>
> Jacob
>
> On Sun, Jul 21, 2019 at 3:54 PM Andrew Godwin  wrote:
>
>> Hi everyone,
>>
>> After a long and involved vote, I can announce that the Technical Board
>> has voted in favour of DEP 0009 (Async Django), and so the DEP has been
>> moved to the "accepted" state.
>>
>> As some may have seen, I've started work on adding async support to views
>> (
>> https://github.com/django/django/compare/master...andrewgodwin:async_views)
>> - this is, as the DEP states, the last "blocking" change before we can open
>> up lots of parallel work on making other parts of Django async, and so now
>> the DEP is approved the next step is to work out funding and organisation
>> for future async work.
>>
>> If you are interested in helping with fundraising, then please get in
>> touch with me directly; I have some ideas about how to structure it, but I
>> could do with some people to help out. Otherwise, stay tuned for more
>> information about how to get involved contributing and what to work on!
>>
>> Andrew
>>
>> On Sat, Jun 8, 2019 at 9:14 AM Andrew Godwin  wrote:
>>
>>>
>>>
>>> On Sat, Jun 8, 2019 at 3:14 AM Pascal Chambon 
>>> wrote:
>>>
 Hello,

 There is something a little scary for me, in changing all the core of
 Django to async, when this really helps only, imho, a tiny fraction of
 users : websocket/long polling services, and reddit-like sites with
 thousands+ hits per second. For most webpages and webservices, async
 artillery sounds quite overkill.

 Are cpython threads inefficient ? As far as I know they are only kernel
 threads constrained by the Gil, so they shouldnt wake up when they are
 blocked on io syscalls/mutexes (or do they?), and context switches remain
 acceptable compared to the slowness of python itself.

>>>
>>> It's fine when you only at 5/10 threads - which, notably, is what most
>>> WSGI servers run at. When you get to the hundreds, though, you start losing
>>> a large proportion of your execution time (tens of percent, in some cases).
>>>
>>>

 We used to provide provisioning and automatic authentication for 20
 million users, with partner webservices tar-pitting us for sometimes 1mn.
 The nightmare scenario. But with 2 machines, 1 process by core, and 800
 threads by process, it did the job, enough for us to answer millions of
 hits a day. Without even relying on other no-recoding optimizations like
 pypy or gevent.

 Async would certainly have been a relevant techno if we had known in
 advance that our partners would be so slow, but avoiding the extra
 complexity burden of this style (where a single buggy dependency can block
 all requests in a process, where all modules have to be recoded for it) was
 also a huge benefit. And the limited thread pool also protected our DB from
 unbearable loads.

>>>
>>> Please remember that even after this change, Django will still expect
>>> you to write synchronously by default, and not impose any of that extra
>>> complexity on you. We will only swap out the "native" implementation of
>>> things if the performance matches (within ~10%) or exceeds that of the
>>> synchronous version when there's a couple of threads going; it's expected
>>> this will largely be the case due to the direct benefits of idling less.
>>>
>>> But - the plan is not to make it more complex by default (you only have
>>> to interact with the async if you want to) or slower.
>>>
>>>

 It's very nice if a proper async ecosystem emerges in python, but I
 fear lots of people are currently jumping into it without a need for such
 performance, and at the expense of lots of much more important matters like
 robust ess, correctness, compatibility... like it happened for docker and
 microservices, transforming into fragile bloatwares simple intranets, which
 just needed a single django codebase deployed in a single container.

 A few days ago I audited a well used django module, the current user
 was stored in a global variable (!!!). People might eventually fix that
 ticket, use threadlocals, and then switch to a future django-async without
 realizing that the security issue has come back due to the way async works.

 Still I hope I'm wrong, that the performance gains will prove worth the
 software fragmentation and complexity brought by asyncio, but I still dont
 understand them for 99% users... Especially as long as key-in-hand
 solutions like greenlets exist for power users.


>>> I agree with you that there's a chance this is all useless and does

Re: Django Async DEP

[Ehigie Aito]

Django 3.0?

On Sun, Jul 21, 2019 at 9:02 PM Andrew Godwin  wrote:

> I'll ask permission and then summarise the points raised back out here!
>
> Andrew
>
> On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss 
> wrote:
>
>> Congratulations, and great news!
>>
>> I hope the TB will consider sharing details and/or a summary of the "long
>> and involved vote"; I'll bet there's a bunch the broader community could
>> learn from the specifics.
>>
>> Jacob
>>
>> On Sun, Jul 21, 2019 at 3:54 PM Andrew Godwin 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> After a long and involved vote, I can announce that the Technical Board
>>> has voted in favour of DEP 0009 (Async Django), and so the DEP has been
>>> moved to the "accepted" state.
>>>
>>> As some may have seen, I've started work on adding async support to
>>> views (
>>> https://github.com/django/django/compare/master...andrewgodwin:async_views)
>>> - this is, as the DEP states, the last "blocking" change before we can open
>>> up lots of parallel work on making other parts of Django async, and so now
>>> the DEP is approved the next step is to work out funding and organisation
>>> for future async work.
>>>
>>> If you are interested in helping with fundraising, then please get in
>>> touch with me directly; I have some ideas about how to structure it, but I
>>> could do with some people to help out. Otherwise, stay tuned for more
>>> information about how to get involved contributing and what to work on!
>>>
>>> Andrew
>>>
>>> On Sat, Jun 8, 2019 at 9:14 AM Andrew Godwin 
>>> wrote:
>>>


 On Sat, Jun 8, 2019 at 3:14 AM Pascal Chambon 
 wrote:

> Hello,
>
> There is something a little scary for me, in changing all the core of
> Django to async, when this really helps only, imho, a tiny fraction of
> users : websocket/long polling services, and reddit-like sites with
> thousands+ hits per second. For most webpages and webservices, async
> artillery sounds quite overkill.
>
> Are cpython threads inefficient ? As far as I know they are only
> kernel threads constrained by the Gil, so they shouldnt wake up when they
> are blocked on io syscalls/mutexes (or do they?), and context switches
> remain acceptable compared to the slowness of python itself.
>

 It's fine when you only at 5/10 threads - which, notably, is what most
 WSGI servers run at. When you get to the hundreds, though, you start losing
 a large proportion of your execution time (tens of percent, in some cases).


>
> We used to provide provisioning and automatic authentication for 20
> million users, with partner webservices tar-pitting us for sometimes 1mn.
> The nightmare scenario. But with 2 machines, 1 process by core, and 800
> threads by process, it did the job, enough for us to answer millions of
> hits a day. Without even relying on other no-recoding optimizations like
> pypy or gevent.
>
> Async would certainly have been a relevant techno if we had known in
> advance that our partners would be so slow, but avoiding the extra
> complexity burden of this style (where a single buggy dependency can block
> all requests in a process, where all modules have to be recoded for it) 
> was
> also a huge benefit. And the limited thread pool also protected our DB 
> from
> unbearable loads.
>

 Please remember that even after this change, Django will still expect
 you to write synchronously by default, and not impose any of that extra
 complexity on you. We will only swap out the "native" implementation of
 things if the performance matches (within ~10%) or exceeds that of the
 synchronous version when there's a couple of threads going; it's expected
 this will largely be the case due to the direct benefits of idling less.

 But - the plan is not to make it more complex by default (you only have
 to interact with the async if you want to) or slower.


>
> It's very nice if a proper async ecosystem emerges in python, but I
> fear lots of people are currently jumping into it without a need for such
> performance, and at the expense of lots of much more important matters 
> like
> robust ess, correctness, compatibility... like it happened for docker and
> microservices, transforming into fragile bloatwares simple intranets, 
> which
> just needed a single django codebase deployed in a single container.
>
> A few days ago I audited a well used django module, the current user
> was stored in a global variable (!!!). People might eventually fix that
> ticket, use threadlocals, and then switch to a future django-async without
> realizing that the security issue has come back due to the way async 
> works.
>
> Still I hope I'm wrong, that the performance gains will prove worth
> the software fragmentation and complexity brought by asyncio, but

Re: Django Async DEP

[Andrew Godwin]

On Sun, Jul 21, 2019 at 1:11 PM Ehigie Aito  wrote:

> Django 3.0?
>

Django follows time-based releases; what's in Django 3.0 will depend on
when we can get it landed. At the moment I am optimistic something will
make it in, but I make no promises!

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/CAFwN1ur%2BgWcjavb6%2B-_qH0bE-P2qVOuWULVq%3DuNRq5j-TWkpTA%40mail.gmail.com.

Re: Django Async DEP

[Andrew Godwin]

OK, here is some of the feedback from the Technical Board, aggregated
together:

* There were questions around contextvars and if they might supplant the
need for a threading.local override - I clarified why this doesn't work in
the DEP.

* Several board members queried around how we might distinguish async
versions of functions/method from sync ones, and if we could get core
Python to implement a better, language-level way of having both under the
same name. For now, the conclusion is to pursue just having them as
separate names, likely under a sub-object (so, for example, cache.get and
cache.async.get), and ensure the documentation is very clear when we must
present both

* Templating was queried by multiple people, with one board member
referencing the streaming template work that happened in the past (
https://github.com/django/django/pull/11157), and another wondering if we
should just say that Django templates are sync forever and potentially look
at Jinja2 for async support if users desire. My personal takeaway from this
is that we should address async templates on its own, with a team who can
do some experimentation and come back with a recommendation.

* There was a concern over the fact that asgiref is now a core dependency
of Django, joining tzdata, and that there had already been some negative
user reactions about this in the wild. As part of helping out this problem,
I removed asgiref's own dependency on async_timeout, so it's now just a
single flat package.

* There was concern about users being able to opt out of async mode should
it cause a performance hit (like we allow with localisation), and another
member mentioned the djangobench benchmark project. I stated that if adding
async to the core flow impacted synchronous use by 10% we would find a way
to make it strictly opt-in, as well as my personal belief that this may
actually make things faster even for synchronous code and projects. I also
said that I'd like to revive regular benchmarking and add an async one in
to both help stop potential slowdown caused by adding async, as well as
illustrating the advantage of async code for certain workloads.

* A board member mentioned that the behaviour of transactions is already
tricky, and adding this in might make it worse. I agree with them, but I've
already started looking at ways to keep transactions and threads tied
strictly together and put some explicit safeguards to stop them leaking
across threads. That said, transactions and the ORM are my own personal
biggest worry about this first phase of the project.

* It was pointed out that while Django does not ship a threadlocal for
request, this is a very common pattern and we need to make sure it works. I
said that asgiref.local.Local is intended to be a drop-in,
backwards-compatible replacement for threadlocal for this very reason; most
projects will merely need to change a single import to get the correct
behaviour.

* There was some questioning about how the debug server should run and if
it should enable the asyncio debug mode. I think it should, but I'm not
sure at what stage we will make an async runserver the default, considering
we will likely have to bring in Daphne or Uvicorn as a dependency to do so.

* The final query I'm going to pull out here was non-technical - that the
Django project has lost many contributors over the years, is essentially in
a maintenance mode, and that we likely do not have the people to staff a
project like this. I agree with the observation that things have
substantially slowed down, but I personally believe that a project like
async is exactly what Django needs to get going again. There's now a large
amount of fertile ground to change and update things that isn't just fixing
five year old bugs.

Hopefully this gives you some idea of the conversation we had. In my years
on the Board, this is by far the most detailed a vote has ever gotten, and
I can only apologise to the incoming board for springing this on them right
after an election!

If anyone on this list would like to continue to talk about the above, or
if a Board member wants to bring their conversation out here, you are all
more than welcome.

Andrew

On Sun, Jul 21, 2019 at 1:02 PM Andrew Godwin  wrote:

> I'll ask permission and then summarise the points raised back out here!
>
> Andrew
>
> On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss 
> wrote:
>
>> Congratulations, and great news!
>>
>> I hope the TB will consider sharing details and/or a summary of the "long
>> and involved vote"; I'll bet there's a bunch the broader community could
>> learn from the specifics.
>>
>> Jacob
>>
>> On Sun, Jul 21, 2019 at 3:54 PM Andrew Godwin 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> After a long and involved vote, I can announce that the Technical Board
>>> has voted in favour of DEP 0009 (Async Django), and so the DEP has been
>>> moved to the "accepted" state.
>>>
>>> As some may have seen, I've started work on adding async support to
>>> views (
>>> http

Re: Fellow Reports - July 2019

[Mariusz Felisiak]

Week ending July 21, 2019.

*Triaged:*
https://code.djangoproject.com/ticket/30636 - mysqldump crash when 
--defaults-file is not given before other options. (accepted)
https://code.djangoproject.com/ticket/30637 - SearchVectorField and 
SearchVector should be combinable. (accepted)
https://code.djangoproject.com/ticket/30639 - Raise an error on unsupported 
operations following QuerySet.union(). (duplicate)
https://code.djangoproject.com/ticket/30640 - createsuperuser crashes when 
a custom user model contains required fields that overlap with default 
command options. (wontfix)
https://code.djangoproject.com/ticket/30641 - Update docs for using CSRF 
with Ajax. (wontfix)
https://code.djangoproject.com/ticket/30618 - AppConfig.name should be a 
full python path when using the optional directory. (wontfix)
https://code.djangoproject.com/ticket/30643 - Docs incorrectly state that 
time zone support is disabled by default. (duplicate)
https://code.djangoproject.com/ticket/30642 - Unable to include default 
value in column_sql when creating new model. (invalid)
https://code.djangoproject.com/ticket/30329 - ImproperlyConfigured 
exceptions should be raised immediately. (fixed)
https://code.djangoproject.com/ticket/3 - QuerySet constructed with 
.union() should raise an exception on unsupported filter() attempt. 
(duplicate)https://code.djangoproject.com/ticket/30644 - Postgres 
introspection don't filter on visible objects. (accepted)
https://code.djangoproject.com/ticket/30646 - close_if_unusable_or_obsolete 
fails to close unusable connections. (wontfix)
https://code.djangoproject.com/ticket/30648 - Overriding get_context_data() 
is unnecessary in the "Using FormMixin with DetailView" example. (acce[ted)
https://code.djangoproject.com/ticket/28439 - When() crashes with 
ValidationError with models using UUID as primary key. (fixed)
https://code.djangoproject.com/ticket/30649 - Implement MakeValid() for 
non-column values. (wontfix)
https://code.djangoproject.com/ticket/30638 - Allow the per-database 
TIME_ZONE option on databases that support timezones. (wontfix)
https://code.djangoproject.com/ticket/30083 - Model instance state not 
correctly set when initializing a model with Model.from_db() (wontfix)

*Reviewed/committed:*
https://github.com/django/django/pull/11565 - Fixed explanation of how to 
automatically create tables in database.
https://github.com/django/django/pull/11567 - Fixed #30636 -- Fixed options 
ordering when cloning test database on MySQL.
https://github.com/django/django/pull/10478 - Fixed #29824 -- Added support 
for database exclusion constraints on PostgreSQL.
https://github.com/django/django/pull/11575 - Fixed #30648 -- Removed 
unnecessary overriding get_context_data() from mixins with CBVs docs.
https://github.com/django/django/pull/11566 - Fixed #30593 -- Added support 
for check constraints on MariaDB 10.2+.
https://github.com/django/djangoproject.com/pull/904 - Fixed #902 -- 
Updated to Django==2.2.3
https://github.com/django/djangoproject.com/pull/893 - Trimmed 
search_results translation messages.

*Reviewed:*
https://github.com/django/django/pull/11452 - Fixed #12990 -- Added 
JSONField model field.

*Authored:*
https://github.com/django/django/pull/11574 - Refs #30547 -- Clarified that 
partial UniqueConstraints don't affect model validation.
https://github.com/django/django/pull/11576 - Refs #30083 -- Clarified 
database state of instances in signals.pre_init docs.
https://github.com/django/django/pull/11577 - Simplified 
get_key_columns()/get_relations() introspection methods for PostgreSQL.

Best regards,
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/92d51e07-4705-4f9c-a79d-87ac41288bbc%40googlegroups.com.