Django 3.0 beta 1 released

2019-10-14 Thread Mariusz Felisiak

We've made the second release on the way to Django's next major
release, Django 3.0! With a month and a half until the final release,
we'll need timely testing from the community to ensure a stable
release. Check out the blog post:

https://www.djangoproject.com/weblog/2019/oct/14/django-30-beta-1-released/

--
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/d297e919-019e-bf04-e2b5-0593fe7751a0%40gmail.com.


Re: Fellow Reports - October 2019

2019-10-14 Thread Mariusz Felisiak
Week ending October 13, 2019.

*Triaged*:
https://code.djangoproject.com/ticket/30845 - Simple explanation of default 
app folder structure. (invalid)
https://code.djangoproject.com/ticket/30844 - Add after_db_init() hook 
method to model (wontfix)
https://code.djangoproject.com/ticket/30843 - New argument for FileField 
and descendants: size_field. (wontfix)
https://code.djangoproject.com/ticket/30839 - Form Field’s __deepcopy__ 
does not (deep)copy the error messages. (accepted)
https://code.djangoproject.com/ticket/30841 - Prevent using __isnull lookup 
with non-boolean value. (accepted)
https://code.djangoproject.com/ticket/30847 - Geodjango not respecting 
spatial_index=False. (worksforme)
https://code.djangoproject.com/ticket/30848 - GeoDjango GeometryZ Field 
Wanted. (wontfix)
https://code.djangoproject.com/ticket/30850 - Overriding the default admin 
requires the custom admin site not to be in admin.py. (duplicate)
https://code.djangoproject.com/ticket/30846 - postgis backend doesn't 
respect custom index names. (accepted)
https://code.djangoproject.com/ticket/30851 - Humanize isn't fully 
translated into Armenian. (invalid)
https://code.djangoproject.com/ticket/30853 - field__foo__contains dont 
work in 2.2.6 on JSONField (duplicate)
https://code.djangoproject.com/ticket/30854 - Selecting multiple 
FilteredRelation's returns only the last one. (accepted)
https://code.djangoproject.com/ticket/30855 - JSON has_key causes 
'TypeError: can only concatenate tuple (not "list") to tuple' in Django 
2.2.6 (duplicate)
https://code.djangoproject.com/ticket/30857 - When subclassing a model 
field, max_length cannot be passed as an argument to __init__(). (invalid)
https://code.djangoproject.com/ticket/30863 - Queryset __repr__ can 
overload a database server in some cases. (duplicate)
https://code.djangoproject.com/ticket/29241 - ConditionalGetMiddleware and 
x-sendfile. (wontfix)
https://code.djangoproject.com/ticket/30870 - "migrate --plan" outputs 
"IRREVERSIBLE" on RunPython operations without docstrings. (accepted)
https://code.djangoproject.com/ticket/30869 - Setting to confirm 
destructive/weird migrations. (wontfix)
https://code.djangoproject.com/ticket/30871 - override_settings() does not 
restore partially deleted settings. (invalid)
https://code.djangoproject.com/ticket/30868 - ForeignKey's to_field 
parameter gets the old field's name when renaming a PrimaryKey. (accepted)
https://code.djangoproject.com/ticket/30873 - I'm looking option to get the 
selected value from MultipleChoiceField (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/11851 - Refs #10348 -- Doc'd that 
ModelAdmin ignores list_select_related when QuerySet.select_related() was 
already called.
https://github.com/django/django/pull/11871 - Fixed #28273 -- Doc'd fast 
nullable column creation with defaults.
https://github.com/django/django/pull/11880 - Fixed #30839 -- Fixed 
Field.__deepcopy__() so forms don't share error messages.
https://github.com/django/django/pull/11445 - Fixed #28790 -- Doc'd how to 
avoid running certain test classes in parallel.
https://github.com/django/django/pull/11888 - Improved performance of 
django.template.base.Parser.
https://github.com/django/django/pull/11885 - Fixed #30856 -- Combined 
fast-delete queries by model during cascade deletion.
https://github.com/django/django/pull/11887 - Fixed #30860 -- Disabled 
unneeded NULLS FIRST/LAST workaround on SQLite 3.30+.
https://github.com/django/django/pull/11884 - Fixed #11097 -- Added note 
about parent link fields in formsets for multi-table inheritance models.
https://github.com/django/django/pull/11141 - Fixed #30300 -- Allowed 
migrations to be loaded from directories without __init__.py files.
https://github.com/django/django/pull/11891 - Fixed #30812 -- Made 
ConditionalGetMiddleware set ETag only for responses with non-empty content.
https://github.com/django/django/pull/11829 - Fixed #23755 -- Added support 
for multiple field names in the no-cache Cache-Control directive to 
patch_cache_control().
https://github.com/django/django/pull/11901 - Fixed #30854 -- Fixed 
QuerySet.select_related() with multiple FilteredRelations.
https://github.com/django/django/pull/11863 - Fixed #30826 -- Fixed crash 
of many JSONField lookups when one hand side is key transform.
https://github.com/django/django/pull/11003 - Fixed #30014 -- Fixed 
ModelChoiceField validation when initial value is a model instance.
https://github.com/django/django/pull/11760 - Clarified that 
SECURE_REDIRECT_EXEMPT patterns should not include leading slashes.

*Reviewed:*
https://github.com/django/django/pull/11892 - Refs #27086 -- Corrections to 
unit testing contributor docs.

*Authored:*
https://github.com/django/django/pull/11890 - Refs #26608 -- Refs #26608 -- 
Fixed DatabaseFeatures.supports_frame_range_fixed_distance on SQLite 3.28+, 
MariaDB 10.2+, and MySQL 8.0.2+.

Best regards,
Mariusz

-- 
You received this message because you are subscribed to the 

Re: Django 3.0 beta 1 released

2019-10-14 Thread Nur Mohsin
Wow... Good news.

On Mon, Oct 14, 2019 at 4:38 PM Mariusz Felisiak 
wrote:

> We've made the second release on the way to Django's next major
> release, Django 3.0! With a month and a half until the final release,
> we'll need timely testing from the community to ensure a stable
> release. Check out the blog post:
>
> https://www.djangoproject.com/weblog/2019/oct/14/django-30-beta-1-released/
>
> --
> 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/d297e919-019e-bf04-e2b5-0593fe7751a0%40gmail.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/CAM0c9Rouvae%2Bos1GrDPTmDijpUNBrN50WJvyaH4fM60-Cj7q%3Dg%40mail.gmail.com.


Re: Stop QuerySet repr from executing queries

2019-10-14 Thread Matt
Created https://github.com/django/django/pull/11917

This patch will print the results of the query (if it has been evaluated). 
I did hit one odd case while writing the tests. Essentially, if you do:

queryset = SomeModel.objects.all()
list(queryset)
SomeModel.objects.create(...)
repr(queryset)

The newly created model won't appear in the repr. I believe the existing 
behavior will show the newly created object. I'm still not a huge fan of 
this repr behavior (I lean towards just displaying the SQL like 
RawQuerySet).

I just noticed felixxm closed the original ticket. Unfortunately, I don't 
think I'm advertising the severity of this issue very well and most people 
are probably never going to encounter it (and if they do, it's probably 
their own fault). So to be more explicit about the problem...

*How to crash your production database with Django:*

   1. Use an error reporting system like Sentry
   2. Have a database table with millions of rows (the more the "better")
   3. Have a Django model representing the above table, with a default sort 
   of a non-indexed field
   4. Have a local variable somewhere in the stack like `queryset = 
   HugeTable.objects.all()` (assume it doesn't get "refined down" until deeper 
   in your code)
   5. Trigger an uncaught exception
   6. Your error reporting layer will call repr() on that queryset local 
   variable.
   7. repr(queryset) will trigger your database server to do SELECT ... 
   FROM HugeTable ORDER BY NonIndexedColumn LIMIT 21 (locking it up)
   8. Bonus: Trigger all of the above on all your wsgi processes
   
In short, just call repr(BigTable.objects.all()) (where BigTable has an 
ordering on an non-indexed column and lots of rows)



On Thursday, October 10, 2019 at 8:50:31 AM UTC-7, Matt wrote:
>
> repr(some_queryset) will execute the query and display some results from 
> the query. This is done because it's (somewhat) helpful for debugging.
>
>
> https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248
>
> This has caused at least two people to scratch their heads about odd 
> queries being generated, and it crashed my production database yesterday.
>
> See #20393  and #30863 
> 
>
> Luke Plant has said:
>
> ... you have a conflict between the goal of being information rich and 
>> with *always* being useful for debugging. In general, automatically 
>> seeing the results is information rich and is useful in debugging, but 
>> sometimes it causes further problems.
>>
>> I have thought about it, and with this conflict of goals, I think we are 
>> going to have to err on the side of the current behaviour. It is possible 
>> to work around by not calling repr on QuerySets in your middleware, and 
>> there are too many people who will be upset (or have problems with their 
>> own debugging facilities) by changing this.
>>
>
> One reason people love Django is because of its attention to things like 
> debug-ability. I can certainly see the argument here. However, I want to 
> press on the desirability of this feature.
>
> The argument that you can work around it by not calling repr is certainly 
> true, but in practice, I don't think it's reasonable. Production error 
> reporting tools (like Sentry and New Relic) will call repr when reporting 
> on exceptions.
>
> I see this behavior as being analogous to a file object printing the first 
> 21 characters of a file, which it doesn't do (for good reason, I would 
> imagine):
>
> >>> f = open("foo.py")
> >>> repr(f)
> "<_io.TextIOWrapper name='foo.py' mode='r' encoding='UTF-8'>"
> >>>
>
> I think we ought to reconsider the behavior of repr on QuerySets. I'm of 
> the opinion that we should scrap it completely. It could be replaced by 
> something that generates the SQL that would be executed (although that may 
> be tricky), or some kind of representation of the query filter. 
>
> Any thoughts?
>

-- 
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/fef2d187-196c-43cc-8935-8b0f4779d727%40googlegroups.com.


Django 3.0 Release Notes - ASGI

2019-10-14 Thread Josh Smeaton
A co-worker just linked me to 
https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and asked 
me (basically) if we can start doing all kinds of async work in one of our 
projects. Unfortunately, I didn't really know how to answer.

Preface: I haven't followed the ASGI plan very closely (I read the DEP and 
have a vague understanding of the vision).

It's my understanding that there's only very limited support for ASGI, and 
most features of Django won't work properly when running under ASGI. But 
that's not clear from reading the release notes or the deploy on ASGI 
section of the docs. Should we have a section in the docs that show what is 
and is not supported, along with examples?

It'd be good to have a spot in the docs to point to that shows what is in 
and out of scope for each milestone.

Thoughts?

-- 
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/9b11ecd8-997f-4edc-a627-5523da611a55%40googlegroups.com.


Re: Django 3.0 Release Notes - ASGI

2019-10-14 Thread Markus Holtermann
Good point, Josh.

I think we should either add an "experimental" note to the ASGI notes or 
introduce an "Experimental changes" section (I'm open to other naming 
suggestions)

/Markus

On Tue, Oct 15, 2019, at 9:45 AM, Josh Smeaton wrote:
> A co-worker just linked me to 
> https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and 
> asked me (basically) if we can start doing all kinds of async work in 
> one of our projects. Unfortunately, I didn't really know how to answer.
> 
> Preface: I haven't followed the ASGI plan very closely (I read the DEP 
> and have a vague understanding of the vision).
> 
> It's my understanding that there's only very limited support for ASGI, 
> and most features of Django won't work properly when running under 
> ASGI. But that's not clear from reading the release notes or the deploy 
> on ASGI section of the docs. Should we have a section in the docs that 
> show what is and is not supported, along with examples?
> 
> It'd be good to have a spot in the docs to point to that shows what is 
> in and out of scope for each milestone.
> 
> Thoughts?
> 
>  -- 
>  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/9b11ecd8-997f-4edc-a627-5523da611a55%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/5f103d87-7128-4ce3-8491-a0ed02e0b18a%40www.fastmail.com.


Re: Django 3.0 Release Notes - ASGI

2019-10-14 Thread Andrew Godwin
I agree - we need to communicate that ASGI support does *not *mean you can
start writing async def views. I think we should put a big disclaimer to
that effect next to it in the release notes and say it should be coming
next release.

Andrew

On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton  wrote:

> A co-worker just linked me to
> https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and
> asked me (basically) if we can start doing all kinds of async work in one
> of our projects. Unfortunately, I didn't really know how to answer.
>
> Preface: I haven't followed the ASGI plan very closely (I read the DEP and
> have a vague understanding of the vision).
>
> It's my understanding that there's only very limited support for ASGI, and
> most features of Django won't work properly when running under ASGI. But
> that's not clear from reading the release notes or the deploy on ASGI
> section of the docs. Should we have a section in the docs that show what is
> and is not supported, along with examples?
>
> It'd be good to have a spot in the docs to point to that shows what is in
> and out of scope for each milestone.
>
> Thoughts?
>
> --
> 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/9b11ecd8-997f-4edc-a627-5523da611a55%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/CAFwN1ur9uqHjSn1-Ynj1CVT%2B5AF4X2J3-nRCZ0dF4ZUWeJG1MQ%40mail.gmail.com.


Re: Fellow Reports -- October 2019

2019-10-14 Thread Carlton Gibson
Hi All, 




Calendar Week 41 -- ending 13 October.


Triaged:

https://code.djangoproject.com/ticket/30872 -- 
ManagementUtility.fetch_command prints "No Django settings 
specified." even if they are. (Accepted)
https://code.djangoproject.com/ticket/30864 -- Document and endorse 
django.utils.decorators.classproperty (Accepted)
https://code.djangoproject.com/ticket/30865 -- Document that some 
DATABASES['OPTIONS'] are not passed to dbshell database shell. 
(Accepted)
https://code.djangoproject.com/ticket/30862 -- Explicitly set `secure` for 
SameSite: None cookies. (Accepted)
https://code.djangoproject.com/ticket/30858 -- Ambiguous phrasing in the 
Error Reporting documentation (Accepted)
https://code.djangoproject.com/ticket/30852 -- Technical 500 page's 
ExceptionReporter may crash when given a POST payload with an invalid 
boundary (Duplicate of #30227)
https://code.djangoproject.com/ticket/30859 -- Enable the 
supports_aggregate_filter_clause database feature on SQLite >= 3.30 
(Accepted)
https://code.djangoproject.com/ticket/30860 -- Skip OrderBy.as_sqlite on 
SQLite >= 3.30 (Accepted)
https://code.djangoproject.com/ticket/30856 -- Combine fast delete queries 
(Accepted)
https://code.djangoproject.com/ticket/30837 -- Changing password reset 
email template name to .txt extension (wontfix)



Reviewed:

https://github.com/django/django/pull/11900 -- Fixed #56 -- Add 
AutoField.is_signed argument
https://github.com/django/django/pull/11829 -- Fixed #23755 -- 
`cache-control` now supports multiple `no-cache` fields
https://github.com/django/django/pull/11872 -- Fixed #30808 -- Added the 
Django Forum to contributing index.
https://github.com/django/django/pull/11893 -- Fixed #11385 -- Made 
forms.DateTimeField accept ISO 8601 date inputs.
https://code.djangoproject.com/ticket/30862 -- Explicitly SameSite: None 
cookies.
https://github.com/django/django/pull/11890 -- Refs #26608 -- Fixed 
DatabaseFeatures.supports_frame_range_fixed_distance on SQLite 3.28+.
https://github.com/django/django/pull/11881 -- Fixed #30849 -- Added 
autodetector signals.
https://github.com/django/django/pull/11882 -- Fixed #28790 -- Doc'd 
how to avoid running certain test classes in parallel.
https://github.com/django/deps/pull/65 -- First draft of DEP for static-ish 
typechecking for Django
https://github.com/django/django/pull/11870 -- Password reset template html 
to txt with fallback
https://code.djangoproject.com/ticket/30841 -- Prevent using __isnull 
lookup with non-boolean value.
https://code.djangoproject.com/ticket/20456 -- Easier unit testing for 
class-based views



Authored:

https://github.com/django/django/pull/11892 -- Refs #27086 -- Corrections 
to unit testing contributor docs.
https://github.com/django/django/pull/11889 -- Fixed #30858 -- Clarified 
that AdminEmailHandler processes all 5xx responses.



Kind Regards,

Carlton

-- 
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/10a34f51-938e-407a-972a-9e2f358483c6%40googlegroups.com.