GSoD - Google Season of Docs

[Aksh Gupta]

Hi,

I'd love to improve the 'Contributing Guide' as a part of GSoD this year. 
I have gone through the Guide myself to start contributing to the project, 
and I agree that it is indeed overwhelming to follow.

Getting new contributors is a crucial part of any big project. I would love 
to give my best to make it a better read and easier to follow for potential 
future contributors (including me).

Looking forward to a wonderful interaction with the community!

Kind Regards,

Aksh

-- 
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/7d8a4dde-565b-46a9-837d-8db14e8a886c%40googlegroups.com.

Re: Clear all filters

[Mariusz Felisiak]

OK, I added new ticket https://code.djangoproject.com/ticket/31603.

Thanks y'all

-- 
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/d0b554c5-43c7-4cfe-8a11-4bc05323636f%40googlegroups.com.

Re: Proposal for Table Functions

[Ahmad A. Hussein]

Concerning tests, I did not mean to comment about the tests you wrote. I 
used the third party py-test django app as an example of an app that does 
need work in core to function better, not as a comment about your usage of 
tests. You're more than free to work the way you want to :) (I like pytest 
too)

If there's an optimization to be had in including table functions and it'll 
be backwards compatible without breaking anything, then I think there's 
merit in the idea. I suggest you open a ticket on the issue tracker and 
mention how significant the optimization was. It'll help with getting this 
new feature adopted.

You can open it here 



On Monday, May 18, 2020 at 8:31:04 AM UTC+2, Petr Přikryl wrote:
>
> ad 1. I was testing it on PostgreSQL only. But:
>
>- Oracle is feasible through custom extendings in compiler 
>
> https://livesql.oracle.com/apex/livesql/file/content_C87XCH8SE085LMS3C5KR03VFS.html
>- MySQL is also feasible https://stackoverflow.com/a/23421816/1763888
>- SQLite has some special limited table functions which should be 
>syntax-compatible with Postgres 
>https://www.sqlite.org/vtab.html#tabfunc2
>
> ad 2. Yes, "it is necessary". Because I must do some nasty hacks in my 
> gist. For example:
>
>- SQL regex parsing 
>
> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a#file-function-py-L189.
>  
>Which could be removed if base method would know about parameters.
>- Classic "Join" overriding 
>
> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a#file-function-py-L277.
>  
>I don't like it because I need work with "level" (order) of joins to map 
> it 
>to user lookups correctly. If ithis would be in core, then the lookups 
> from 
>"filter" could be merged witth lookups from "table_function" more easily. 
>There is also possibility to merge logic from table_function into filter 
>and use only filter method for passing parameters into table functions.
>
> ad 3. The use case is optimization for me. Because I had SQL View with 
> recursion. The View was mapped into Django through model. But operations 
> with this view takes long time for my app. So I found out that I can 
> optimize that using table function instead view with parameter limiting the 
> recursion depth. But I couldn't switch view to table function because no 
> ORM support. With this gist I could.
>
> ad tests. I used them because I am used to use them :-). And I think that 
> it should be re-writable to classic Django tests.
>
> Petr
>
>
> Dne neděle 17. května 2020 23:08:08 UTC+2 Ahmad A. Hussein napsal(a):
>>
>> I'm not an expert or even an amateur at the ORM, but here are my thoughts 
>> on the matter:
>> 1. Does it carry over well across the four databases?
>> 2. Is it necessary to include it as part of core versus a third-party app?
>> 3. What specific use case will benefit from adopting this idea?
>>
>> I ask the second question because it seems from your gist that you don't 
>> need your proposal to be part of core for it to work. It seems it would 
>> work completely well and flourish even as a third-party app given how 
>> you're subclassing the API and expanding on its usage. Contrast this with 
>> django-pytest for example that can have a harder problem running pytest on 
>> Django due to how the test runner is currently built (namely that setup 
>> assumes a subclass of the Django test runner).
>>
>> Regards,
>> Ahmad
>> On Sun, May 17, 2020 at 4:36 PM Petr Přikryl  wrote:
>>
>>> Hi, I have just implemented Table Function support on Django 2.1. What 
>>> do you think about adopting it into Django itself? 
>>>
>>> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a
>>>
>>> It is all about passing function parameters into BaseTable and Join 
>>> classes 
>>> https://github.com/django/django/blob/master/django/db/models/sql/datastructures.py
>>>
>>> Here are other thoughts which were inspiring me 
>>> https://schinckel.net/2019/10/31/functions-as-tables-in-django-and-postgres/
>>>
>>> Thanks,
>>> Petr
>>>
>>> -- 
>>> 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/6d16fdfc-332f-4a72-83ae-04ee5c9fd28a%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

Re: Clear all filters

[Markus Holtermann]

I tend to agree with Adam.

>From a UI/UX perspective, the location where the "Clear all filters" button 
>is, as well as the wording, suggest to me that it's only the filters on the 
>right side. The search query, while technically filtering the query set, 
>doesn't seem like a filter in the UI.

I'd potentially argue otherwise if the search field was in the filter box on 
the right.

Additionally, looking at it from the back-end, search terms and filters have 
nothing in common except for the queryset.

Cheers,

Markus


On Mon, May 18, 2020, at 11:10 AM, Mariusz Felisiak wrote:
> > I disagree Mariusz. I would NOT expect this. The "Clear all filters" button 
> > is grouped with the filters, visually separate from the search and sort 
> > controls. It's a very legitimate use case to clear the filters and maintain 
> > the search or sort, and quite a common workflow when trying to find a 
> > particular object.
> 
> The idea of this feature was to remove all filters and *search 
> criteria* in one click (see the ticket description[2]). The first 
> proposition was to put this link in actions [2], but I proposed moving 
> it to filters. I'm not sure if link for clearing only filters is still 
> necessary (and it wasn't the intention of reporter), we can remove this 
> feature if it's misleading. Link to the right of the search box ("X 
> total") already removes the entire query string, so ...
> 
> > Additionally, I see that the link only preserves the _popup=1 query param. 
> > if users have extended their admin views with any extra query params, they 
> > will also be wiped, which is less than helpful. I know I have extended the 
> > admin with extra params before e.g. to control the queryset.
> 
> Link to the right of the search box ("X total") that was added in 2005 
> [3] do the same. We should probably use `add_preserved_filters`.
> 
> [1] https://code.djangoproject.com/ticket/27888
> [2] https://github.com/django/django/pull/12351#issuecomment-577415747
> [3] 
> https://github.com/django/django/commit/9dda4abee1225db7a7b195b84c915fdd141a7260
> 
>  -- 
>  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/ed3810c9-bb86-4e05-97dd-4818efa1617c%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/a366340a-9b8e-4ac5-9478-10380680de99%40www.fastmail.com.

Re: Fellow Reports - May 2020

[Mariusz Felisiak]

Week ending May 17, 2020.

Released Django 3.1a1.

*Triaged:*
https://code.djangoproject.com/ticket/31557 - Use .assertTrue instead of 
.assertIs(..., True) in the unit testing section of the polls tutorial. 
(wontfix)
https://code.djangoproject.com/ticket/31555 - Use .format() and f-strings 
in the polls tutorial. (duplicate)
https://code.djangoproject.com/ticket/31559 - Dial down the SpamBayes 
settings. (invalid)
https://code.djangoproject.com/ticket/31561 - QuerySet could be a 
collections.abc.Set. (wontfix)
https://code.djangoproject.com/ticket/31560 - Circular imports raise 
AppRegistryNotReady. (needsinfo)
https://code.djangoproject.com/ticket/31562 - Namespacing in urls to look 
at default app name. (wontfix)
https://code.djangoproject.com/ticket/31558 - Support the use of boolean 
attribute on properties in the admin. (accepted)
https://code.djangoproject.com/ticket/25236 - Remove ifequal from the 
template language. (accepted)
https://code.djangoproject.com/ticket/31565 - Support GENERATED ALWAYS 
columns for MySQL and PostgreSQL (duplicate)
https://code.djangoproject.com/ticket/31567 - Reversed coordinate order on 
Ubuntu 20.04. (duplicate)
https://code.djangoproject.com/ticket/31568 - Alias used in aggregate 
filtering is incorrect. (accepted)
https://code.djangoproject.com/ticket/31571 - Explain how to transform a 
geometry with GDAL 3 authority axis strategy. (accepted)
https://code.djangoproject.com/ticket/31563 - Document edge case with 
uwsgi, wsgi.file_wrapper and BytesIO. (wontfix)
https://code.djangoproject.com/ticket/31564 - Django fails to return 
HttpResponse message on early response with large uploads. (duplicate)
https://code.djangoproject.com/ticket/31576 - Navigation sidebar hides some 
elements on small windows. (created)
https://code.djangoproject.com/ticket/31578 - Drop support for MySQL 5.6. 
(created)
https://code.djangoproject.com/ticket/31579 - Drop support for PostgreSQL 
9.5 and PostGIS 2.2. (created)
https://code.djangoproject.com/ticket/31580 - Union queryset should raise 
on distinct(). (accepted)
https://code.djangoproject.com/ticket/31581 - Queryset bug when using Q()? 
-- doubles up the counts by doing an extra join. (invalid)
https://code.djangoproject.com/ticket/31584 - Queryset crashes when gruping 
by Exists() on Oracle. (created)
https://code.djangoproject.com/ticket/31585 - Translation: Part of 
tutorial02 to Korean. (invalid)
https://code.djangoproject.com/ticket/31589 - Raw queries do not work if 
any DB content column has the % symbol. (invalid)
https://code.djangoproject.com/ticket/31587 - List filters are selected 
only for queries with explicit __exact lookups. (wontfix)
https://code.djangoproject.com/ticket/31592 - Reverting Django 3.1. to 
Django 3.0.6 raises "binascii.Error: Incorrect padding". (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/12851 - Fixed #25236 -- Deprecated {% 
ifequal %} and {% ifnotequal %} template tags.
https://github.com/django/django/pull/12657 - Optimized Model and QuerySet 
pickling version comparison.
https://github.com/django/django/pull/12892 - Refs #30116 -- Simplified 
regex match group access with Match.__getitem__().
https://github.com/django/django/pull/12159 - Fixed #31034 -- Added a 
navigation sidebar to the admin.
https://github.com/django/django/pull/12878 - Fixed #30678 -- Added support 
for GDAL 3.
https://github.com/django/django/pull/12900 - Refs #30678 -- Added support 
for GDAL 3.1.
https://github.com/django/django/pull/12826 - Used :pep:, :mimetype:, and 
:envvar: roles in various docs.
https://github.com/django/django/pull/12901 - Renamed PROJ.4 to PROJ.
https://github.com/django/django/pull/12908 - Fixed #31580 -- Added error 
messages on distinct() following union(), intersection(), and difference().
https://github.com/django/django/pull/12911 - Fixed #31566 -- Fixed aliases 
crash when chaining values()/values_list() after annotate() with 
aggregations and subqueries.
https://github.com/django/django/pull/12912 - Fixed #31568 -- Fixed alias 
reference when aggregating over multiple subqueries.
https://github.com/django/django/pull/12906 - Fixed #31575, Refs #31034 -- 
Documented admin requires django.template.context_processors.request.
https://github.com/django/django/pull/12916 - Fixed #31590 -- Fixed 
ModelAdmin.date_hierarchy crash with an empty QuerySet.
https://github.com/django/django/pull/12879 - Fixed #31552 -- Added support 
for LZMA and XZ fixtures to loaddata.
https://github.com/django/django/pull/12608 - Fixed #31395 -- Made 
setUpTestData enforce in-memory data isolation.

*Authored:*
https://github.com/django/django/pull/12898 - Fixed E128, E741 flake8 
warnings.
https://github.com/django/django/pull/12899 - Final changes before 
branching stable/3.1.x.
https://github.com/django/django/pull/12907 - Fixed #31576 -- Fixed 
selenium tests with headless mode.
https://github.com/django/django/pull/12909 - Fixed #31579 -- Dropped 
support for PostgreSQL 9.5 and PostGI

Re: Clear all filters

[Mariusz Felisiak]

>
> I disagree Mariusz. I would NOT expect this. The "Clear all filters" 
> button is grouped with the filters, visually separate from the search and 
> sort controls. It's a very legitimate use case to clear the filters and 
> maintain the search or sort, and quite a common workflow when trying to 
> find a particular object.


The idea of this feature was to remove all filters and *search criteria* in 
one click (see the ticket description[2]). The first proposition was to put 
this link in actions [2], but I proposed moving it to filters. I'm not sure 
if link for clearing only filters is still necessary (and it wasn't the 
intention of reporter), we can remove this feature if it's misleading. Link 
to the right of the search box ("X total") already removes the entire query 
string, so ...

Additionally, I see that the link only preserves the _popup=1 query param. 
> if users have extended their admin views with any extra query params, they 
> will also be wiped, which is less than helpful. I know I have extended the 
> admin with extra params before e.g. to control the queryset.
>

Link to the right of the search box ("X total") that was added in 2005 [3] 
do the same. We should probably use `add_preserved_filters`.

[1] https://code.djangoproject.com/ticket/27888
[2] https://github.com/django/django/pull/12351#issuecomment-577415747
[3] 
https://github.com/django/django/commit/9dda4abee1225db7a7b195b84c915fdd141a7260

-- 
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/ed3810c9-bb86-4e05-97dd-4818efa1617c%40googlegroups.com.

Re: Clear all filters

[Adam Johnson]

I disagree Mariusz. I would NOT expect this. The "Clear all filters" button
is grouped with the filters, visually separate from the search and sort
controls. It's a very legitimate use case to clear the filters and maintain
the search or sort, and quite a common workflow when trying to find a
particular object.

Additionally, I see that the link only preserves the _popup=1 query param.
if users have extended their admin views with any extra query params, they
will also be wiped, which is less than helpful. I know I have extended the
admin with extra params before e.g. to control the queryset.

I'm +1 on changing this to take the current query params and remove only
the filter-related ones.

On Mon, 18 May 2020 at 05:36, Mariusz Felisiak 
wrote:

> Hi,
>
>  IMO the current behavior is expected, it is also included in the ticket
> description (see comment[1]).
>
> Best,
> Mariusz
>
> [1] https://code.djangoproject.com/ticket/27888#comment:1
>
> --
> 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/56339b28-59a3-4e41-b364-adf7faa4cb83%40googlegroups.com
> 
> .
>


-- 
Adam

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