RE: Adding generated common table expressions

[Matthew Pava]

I will always suggest that we use the Subquery API to make CTEs. To make them 
recursive, just add a keyword argument (recursive=True) and/or use a union.

It’s been a while since I looked at CTEs, so I might be missing something.

I would hate to see us create an entirely separate API for CTEs.


From: django-developers@googlegroups.com  
On Behalf Of Gaga Ro
Sent: Tuesday, May 10, 2022 9:01 AM
To: Django developers (Contributions to Django itself) 

Subject: Re: Adding generated common table expressions

Hello everyone,

I'm often using django-cte and I'd be thrilled to have CTE in the core.

If I'm not mistaken, the only DB currently supported by Django and not having 
CTE support is MySQL 5.7 (with an end of life in October 2023). I don't know if 
Django 4.2 will support it, but it should be dropped for Django 5.0 as it will 
be released in 2023. So we should have all supported DB supporting CTE when 
this feature would be over.

The ticket (https://code.djangoproject.com/ticket/28919) has been stalled for a 
few years now, this thread as well. I am willing to work on this but I would 
like more information first.

If I try to list all the requirements, we should have:

* A way to add one or more CTE.
* A way to reference the columns from the CTE.
* A way to join them in the main query.
* Setting a CTE as recursive?
* Choosing if a CTE is materialized or not (Not all DB support that, and I'm 
not sure if they all handle it the same way)?
* Insert / delete CTE with returning data?

Do we have a better idea now of what the API should look like?

Thanks.
Le jeudi 17 octobre 2019 à 23:43:49 UTC+2, 
buzzi@gmail.com a écrit :
What do you think of this syntax instead?
q1 = Book.objects.values('author_id').annotate(avg_price=Avg('price'))

q2 = Author.objects.attach('book_prices', q1, id=F('book_prices__author_id'))


def attach(name, queryset, **params):
   # Would look something like this.
   ...


Same sql output.

On Thursday, April 6, 2017 at 9:14:01 AM UTC-4, Anssi Kääriäinen wrote:
On Thursday, April 6, 2017 at 11:53:32 AM UTC+3, Marc Tamlyn wrote:
Regarding Anssi's comments about SubQuery, we do now have that in core as of 
1.11 [0]. It does look like an .attach() approach might actually have been a 
nicer version of this, but on the other hand it's currently implementable 
solely with the Expressions API. It seems like the OuterRef is very similar to 
your queryset.ref(). An even nicer approach using attach could be to say 
qs.attach(q1=some_qs).filter(a=F('q1__b'))?

Hmmh, we have one form of SubQuery, but that's actually for SELECT clause, not 
for FROM clause. I believe the same class won't work for the CTE or subquery in 
FROM clause case.

As for the attach(), seems like a really nice syntax. We do need something for 
generating the join clause for the JOIN. If you look at an example:
q1 = Book.objects.values('author_id').annotate(avg_price=Avg('price'))
q2 = Author.objects.attach(q1=q1)
it needs to create something like:
WITH q1 AS (
SELECT author_id, avg(price) FROM book GROUP BY author_id
)
SELECT 
author.id,
 
author.name
   FROM author
   LEFT JOIN q1 ON 
author.id
 = q1.author_id;

Or, equivalently without the CTE:

SELECT 
author.id,
 
author.name
   FROM author
   LEFT JOIN ( SELECT author_id, avg(price) FROM book GROUP BY author_id) ON 
author.id
 = q1.author_id;

Now, the main points are:
   1. There is no need to design this to be about CTEs. That just limits the 
feature from backends that don't have CTEs without any real benefit. From 
Django's perspective the two above queries are the same.
   2. We do need something for the JOIN ON condition. In some cases Django 
could guess this,

RE: Postgresql Sequence update on data migration

[Matthew Pava]

Please see:
https://docs.djangoproject.com/en/dev/ref/django-admin/#sqlsequencereset

Also, this question is more for the Django Users mailing list than the Django 
Developers mailing list.

From: django-developers@googlegroups.com  
On Behalf Of mohamad ali mehdizadeh
Sent: Wednesday, May 25, 2022 1:23 AM
To: Django developers (Contributions to Django itself) 

Subject: Postgresql Sequence update on data migration

I have a migration from an old table to a new table, so when I migrate also 
data of old table, I try to keep PrimaryKey values the same as old table. so 
every thing go well until I see primary key duplicate value errors from 
Postgresql, I check it and so the Sequence of the new table was not get the 
last_value of the old table,
I doubt that is it the responsibility of developer to take it to the account or 
Django can help developer here?
--
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/fd70a069-0704-40b7-9fe9-e59d87fef22an%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/13a63536e5114b27938bd23d518350c3%40Exchange.ISS.LOCAL.

RE: Optional URL parameters in django.urls.path

[Matthew Pava]

I wonder if maybe you should look at the APPEND_SLASH setting.
https://docs.djangoproject.com/en/4.1/ref/settings/#append-slash


From: django-developers@googlegroups.com  
On Behalf Of Meiyer
Sent: Monday, September 19, 2022 8:59 AM
To: Django developers (Contributions to Django itself) 

Subject: Re: Optional URL parameters in django.urls.path

> One approach is to route two patterns (one with the parameter and one 
> without) to the same URL. Some duplication but (perhaps) easier to read at a 
> glance than either an optional `?` operator.

I thought about that, but it won't work if I want both cases to be named 
similarly (via the `name` parameter). It also feels as duplicating the same 
line.

> Given that — and the alternative re_path() approach being available —  unless 
> there was a particularly simple implementation on display I'd likely be 
> sceptical about an addition here… 🤔

I did a bit of digging in the Django code and in fact it might be quite easy 
(it is also possible I am missing the elephant). django.urls.resolvers defines 
the syntax for the path parameters on line 245 [1] and converts the matches to 
regular expressions on line 290 [2]. Looks like an addition of the '?' to the 
regex after the closing bracket would do it..?


[1] 
https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L245
[2] 
https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L290
--
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/9e0828d7-6434-4fd1-b605-8113342fcba9n%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/204fc422ab5c469b91347ec50068a5a9%40Exchange.ISS.LOCAL.

URLField Validation

[Matthew Pava]

Hello,
I ran into an issue with a models.URLField because it limits the size of the 
field to 200 characters. I find this too short to my use case. I have a valid 
URL to an external website (in academia), and it won't fit in the Django 
URLField.

This took me down a rabbit hole and this very good answer on Stack Overflow:
https://stackoverflow.com/a/417184/603819

Summary:

  1.  The HTTP protocol doesn't place a limit on the number of characters.
  2.  Modern browsers suggest not exceeding 2,000 characters.

There are other details, such as the domain name not exceeding 255 characters, 
but that is a different issue.

Why does Django impose such a limit on URLField? Could we increase it to, say, 
2000 characters? Or even just remove the limitation on it?
Thanks,
Matthew

-- 
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/8e0dccd02c20476b95b84108446020f6%40Exchange.ISS.LOCAL.

RE: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Matthew Pava]

I’m not on the technical board or of any important part of the Django ecosystem 
at all, but I do have an idea. It would be nice to revamp the “name” field in 
the default user model, perhaps to have one field for the name as suggested 
here from the W3C:
https://www.w3.org/International/questions/qa-personal-names

I remember reading elsewhere that there were various important reasons that 
prevented Django from making such a change. Perhaps it would be a good time to 
review that? If there is too much controversy for having a name field at all, 
perhaps eliminating it is the way to go and just have a username field?

Of course, this may go hand-in-hand with Florian’s suggestion of using OpenID 
Connect.

From: django-developers@googlegroups.com  
On Behalf Of Carlton Gibson
Sent: Wednesday, November 16, 2022 12:58 PM
To: django-developers@googlegroups.com
Subject: Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

Thanks Florian

To you and all :) — casting the net wide right now is a good way forward I 
think.
We can scope down for GSoC with some ideas on the table.

(Don't be shy folks. :)

Kind Regards,

Carlton

On Wed, 16 Nov 2022 at 19:52, Florian Apolloner 
mailto:f.apollo...@gmail.com>> wrote:
I do have ideas but no idea about how viable they are in a GSoC context. 
Nevertheless I will put write them down here, maybe we can find smaller scopes 
if needed and if not, it still serves as a list of things that I'd think to be 
interesting:

 * Probably my number one since it kinda is a blocker for me: We need a 
connection pool in Django for async to work. That said connection pools are 
hard to get right ( 
https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
 and 
https://www.psycopg.org/articles/2021/01/17/pool-design/
 ).
 * Production ready webserver 
(https://groups.google.com/g/django-developers/c/q20_Cxske88).
 Maybe only focus on a smaller part first, like reading env variables / config 
files.
 * Depending on how far we get with `request.data` in the meantime, maybe put 
the second steps (adjustable parsers etc) in as GSoC project?
 * I haven't talked with anyone about this one yet, so it might be completely 
bonkers: I think openid connect is here to stay for a while and I'd love to see 
first class support in core for it. I am looking at this from an enterprise 
perspective though; I do not expect a user to choose where to login out of many 
options but rather provide a replacement for the default username/password 
login in an enterprise environment. Most solutions there support openid 
connect. Please note that I am not suggesting to support generic OAuth2/SAML 
and whatnot -- there are great 3rd party packages for that already (which also 
include support for openid connect). I'd just love to be able to install 
arbitrary Django projects and point them to the central authentication server.

I hope this provides some ideas to get more ideas rolling :)

Cheers,
Florian


On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 
carlton...@gmail.com wrote:
Hi all.

Google Summer of Code (GSoC) for 2023 has just been announced.
https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html

Django has participated many times, and it's been a r

RE: Backport for ticket 34063?

[Matthew Pava]

Happy New Year!
I've been reading this thread with keen interest since James first brought it 
up. I think James's rationale is on point and that the back port to fix the bug 
needs to be done.

To the future of async,
Matthew




-Original Message-
From: django-developers@googlegroups.com  
On Behalf Of James Bennett
Sent: Saturday, December 31, 2022 5:18 PM
To: django-developers@googlegroups.com
Subject: Re: Backport for ticket 34063?

On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers 
(Contributions to Django itself) 
wrote:
> In the past I have also been frustrated at particular bug fixes not being 
> backported. But I've gradually come to appreciate just how valuable the 
> backport policy is. It keeps Django forward-facing, and prevents the fellows 
> spending much of their precious time backporting.

In the forum post, which attempted to be a single-place-to-read summary of the 
argument, I pointed out the benefits of the backport policy, and also pointed 
out that making exceptions to it from time to time has happened and without ill 
effect. I also explained why I believe *not* backporting this runs counter to 
the goals the backport policy is theoretically supposed to achieve, and why an 
exception to backport this fix is correct.

As I said above:

> So I ask that people actually read and engage with that in future 
> replies. This is the bare minimum of respect and good faith that can 
> be expected of participants in discussions on this and other forums 
> concerning Django and its development.

I should not have to be asking people to show that basic level of respect and 
good faith. Yet here I am having to ask more than once.

> Also, I’ve learned several techniques to backport within projects when 
> required (e.g. 
> https://us-east-2.protection.sophos.com?d=adamj.eu&u=aHR0cHM6Ly9hZGFtai5ldS90ZWNoLzIwMjAvMDcvMjkvYmFja3BvcnRpbmctYS1kamFuZ28tb3JtLWZlYXR1cmUtd2l0aC1kYXRhYmFzZS1pbnN0cnVtZW50YXRpb24v&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=Y1hFNWxaWTQ0T09pWXE5b3RPL1dlQUw0SGZ5ZVZrUWtnUGppOE1IZExmUT0=&h=f422e964a4e74b35a8571b953844e0bd&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbanDf7stBFoYC6v6v8FXX_gGKbmjVHK647tPXPvUXfXKzFncDtPsW9aPoXXJ46maODTjGRXhVHIPlJFvNLQcISg
>  ). I encourage others to do the same. We could perhaps document some of 
> these techniques (one source: Paul Ganssle’s talk ”What to Do When the Bug is 
> in Someone Else’s Code ”: 
> https://us-east-2.protection.sophos.com?d=ganssle.io&u=aHR0cHM6Ly9nYW5zc2xlLmlvL3RhbGtzLyN1cHN0cmVhbS1idWdz&i=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1&t=ODRyektDQkRpbGtMYk4xemw5K0FxMi9xclVUdmVTR1ZFUWd2NHNKYllwST0=&h=f422e964a4e74b35a8571b953844e0bd&s=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbanDf7stBFoYC6v6v8FXX_gGKbmjVHK647tPXPvUXfXKzFncDtPsW9aPoXXJ46maODTjGRXhVHIPlJFvNLQcISg
>  ).
>
> I also believe that there is no overriding reason to backport in this case. 
> Self-backporting the fix within a project is very feasible—there’s no need 
> for "the request.body workaround" (which is an understandable source of 
> frustration).

This has multiple issues.

First, merely from a technical perspective, a "self backport" for this bug can 
never be as self-contained as you seem to think it would be.
Take, for example, the code I was writing when I tripped over the bug:
a middleware that accesses request.POST, and is part of an application I 
distribute to others. Even if I "self backport" a working AsyncClient into my 
own test suite, anyone who has my middleware configured in their settings now 
has the bug, too, and now *their* test suite must account for it. And then 
anyone who uses that person's code gets "infected" by it and now has to account 
for it.

This leads to either:

1. Everyone must maintain their own copy of the "self backport" of things 
Django shipped, or 2. Everyone relies on a centralized repository for the code.

The first case clearly is bad: it takes not many individual developers at all 
needing to maintain their own "self backports" before the total maintenance 
cost imposed on the community outweighs the maintenance cost Django would have 
incurred by just applying the fix. And given that this is a high-severity bug 
in a key part of a feature Django wants to hype up, I think the current status 
quo of "not many affected" will not last long. And the cost analysis here, it 
should be noted, does *not* include the decreased trust and confidence in 
Django on the part of developers who see such a high-severity bug that Django 
knows about and actively refuses to apply a fix for, even when *all* 
currently-released versions of Django are affected by it.

The second case is worse: the correct name for a centralized repository of 
Django with bugfixes applied is... Django. If we reach the point where people 
in the community are expected to maintain forks just to get documented basic 
functionality like the unit-testing tools working, we are in a truly bad place 
indeed.

Finally, this ignores the question I have aske

RE: Django's automatic admin interface.

[Matthew Pava]

I agree with your sentiment, Tom. I would add that we could get a more 
“SPA-feel” by using HTML over the wire or htmx, which requires minimal 
JavaScript.

From: django-developers@googlegroups.com  
On Behalf Of Tom Carrick
Sent: Wednesday, April 19, 2023 5:07 AM
To: django-developers@googlegroups.com
Subject: Re: Django's automatic admin interface.

IMO, if we were going to modernise the admin (which is laudable), it wouldn't 
be by using JS frameworks or Tailwind, but by simplifying things further, by 
removing the last bits of JQuery, simplifying the HTML and making it more 
semantic, and rewriting the CSS to use a grid based layout and cut down the 
amount of code that is needed to achieve the same result.

I don't have anything against Tailwind or Vue per së, but forcing every Django 
project to have them in the backend seems too opinionated and too much of a 
maintenance burden.

As you mentioned, there are already opinionated packages out there, I'm happy 
they exist, but in my opinion they belong in external packages, not in core.

Tom

On Wed, 19 Apr 2023 at 11:45, Dipankar 
mailto:dipit2...@gmail.com>> wrote:
Sorry if my question is wrong.. .. Not exactly technology I wanted to know 
about the frontend framework like tailwindCSS,react or Vue.

In nutshell I want admin interface with tailwindCSS/React/Vue. any suggestion ?

On Wed, Apr 19, 2023 at 3:01 PM David Sanders 
mailto:shang.xiao.sand...@gmail.com>> wrote:
Hi Dipankar,

Not being rude but serious question: What's the latest front end technology? :)

On Wed, 19 Apr 2023, 7:27 pm Dipankar, 
mailto:dipit2...@gmail.com>> wrote:
Is there any plan to replace Django's automatic admin interface with the latest 
front end technology?
There are several packages available but what if Django itself provides the 
same as core.

--
Warm Regards,
Dipankar B.
--
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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups 
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com.


--
Warm Regards,
Dipankar B.
--
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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%40mail.gmail.com.
--
You received this message because you a

RE: Feature request: making gettext more robust

[Matthew Pava]

I personally like the current behavior. If I don't have a translation prepared 
for a certain text, I want it to fall back on the default text. Saying that, 
how about Django incorporate a management command of some sort that can be used 
to examine the translation files and return the texts that are not translated?

-Original Message-
From: django-developers@googlegroups.com  
On Behalf Of Michiel Beijen
Sent: Friday, June 16, 2023 1:44 AM
To: django-developers@googlegroups.com
Subject: Re: Feature request: making gettext more robust

> On 15 Jun 2023, at 16:15, Tobias Kunze  wrote:
> 
> On 23-06-15 04:29:59, Gergely Kalmár wrote:
>> It seems that gettext is currently quite permissive – it falls back 
>> to the default language whenever a translation file is missing or if 
>> the requested message ID is missing from the translation file. This 
>> can lead to errors slipping through easily.
>> 
>> I think it would be great if there was a way to make gettext raise an 
>> error when the translation file is missing or when the msgid is missing.
> 
> Agreed that this is annoying behaviour, but as far as I can tell, 
> there's not much that Django can do. IIRC we only wrap Python's gettext 
> module¹.
> 
> The relevant method, GNUTranslations.gettext, returns the original 
> message if no translation has been found, and it does so without 
> indicating that this is a fallback response².
> 
> AIUI this behaviour is rooted in GNU's gettext, which (just like the 
> Python
> version) allows you to set a priority list of languages to fall back to³.

In ‘runtime’ indeed it is difficult to get a warning for an untranslated 
string; the best way to go about it is to generate the translation file and 
check for untranslated string in your translation file via some automated check 
such as a Github Action.

The added benefit this has is that if there is a translation string hiding in a 
lesser used part of your app such as the password reset form or so, it will 
still be spotted by the translation file generation, whereas you might 
otherwise miss this if you’re just clicking around in the app.

—
Michiel

--
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/4FE0664B-5E88-460C-826F-F0A85FC09D5B%40x14.nl.

-- 
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/DS7PR15MB59105F07249DA9F12BC11F098258A%40DS7PR15MB5910.namprd15.prod.outlook.com.

RE: Allow applications to register links in the admin interface

[Matthew Pava]

I reviewed some of the history of this ticket. I tend to agree with the 
criticisms of adding something akin to an AdminURL to the Django admin.

However, the idea of custom views to apps in the admin is an idea that I find 
appealing. The history of this ticket features a comment from Tim Graham 
pointing us back to this ticket:
https://code.djangoproject.com/ticket/18665?cversion=1&cnum_hist=3#comment:3
Allowing registering custom admin views with the admin’s index

It was opened 11 years ago and last modified 6 years ago. This points us to an 
external package.
https://github.com/koleror/django-admin-views

It looks like it already has URLs implemented in the Django admin interface, so 
it appears that the volunteer is performing duplicate work. The last update for 
that project was last year.

Our fellows should probably review both tickets to determine if they should be 
closed.
It does appear that Julien Phalip and Jacob Kaplan-Moss both wanted the 
features of Django-admin-views inside the admin app. That might be a 
conversation worth having.

From: django-developers@googlegroups.com  
On Behalf Of Shlomo
Sent: Wednesday, September 6, 2023 9:34 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Allow applications to register links in the admin interface

You have some great points that I definitely overlooked in the initial 
implementation. I don't think that overloading the template is a great solution 
since there are still some features that registered links will add that cannot 
be done with a simple template override.

  *It is easier to selectively show links to users based on the request or 
a custom permission in a method rather than in the template.
  *   Currently each app would have to override the navbar userlinks section 
completely and add their relevant links which would not work if another third 
party app also overrides the same section. Unless {{ block.super }} is used. {{ 
block.super }} is not a great option since it would limit links to be added to 
only the beginning of the block (before VIEW SITE) or the end (after the color 
theme toggle). It is also close to impossible to set the ordering of links when 
using the {{ block.super }} approach.
  *   No Django apps will add a quick links section to the admin and expect 
other apps to use that apps Quick Links section. If the Quick Links section is 
implemented many different apps can utilize this central location to put links. 
(a setting can be added to disable this)
  *   If the app is not sure if the user wants the admin to have the link the 
app can have the link class available and let the user register it.
The implementation can be changed to use a class-based approach. This will work 
similar to how the ModelAdmin class works. The target attribute and onClick can 
be set in the new AdminLink class. For users who need even more control it can 
have a method .to_html() with can be overridden to display the final html link 
element. To decide if a link should be shown to a specific user there can be 
another method called .will_display that will except a request object and will 
return True or False if that user can see the link or not.
This can even use the Django permissions framework by default to determine if 
the user should see the link or not. Similar to how the PermissionRequiredMixin 
works.
You will still be able to override the template if needed the same way as 
before.
I definitely hear that having modifiers using strings can be error prone and 
won't scale well but this can be changed to use ENUMS instead.

The user will be able to override any of these methods to customize how the 
links are displayed.

class RegisterDjango(admin.UrlAdmin):
menu_order = 5
on_click = None
permission_required = ["polls.view_choice", "polls.change_choice"]
url = "https://djangoproject.com"
name = "Django"
target = "_blank"
location = admin.Location.QUICK_LINKS

def get_location(self, request):
return self.location

def get_menu_order(self,request):
return self.menu_order

def get_on_click(self,request):
return self.on_click

def will_display(self,request):
if request.user.has_perms(self.permission_required):
return True
return False

def get_url(self,request):
return self.url

def get_target(self, request):
return self.target

def get_name(self, request):
return self.name

def to_html(self,request):
return f'{self.get_name(request)}'


admin.site.register_url(RegisterDjango)

Most apps will likely add additional links to the Quick Links section, so they 
won't need to be wrapped. This will also cause the navbar not to have so many 
links. If needed there can be a max links setting that can limit the number of 
additional links in the navbar.

As far as link ordering I think that using an approach similar to 
wagtail

RE: Deprecate HttpRequest.is_ajax

[Matthew Pava]

“In my opinion there are not many good reasons to have to change behaviour if a 
request is made via XHR. I think the most common usage is to have a single view 
that returns a JSON response or a HTML response depending on if XHR is used 
(https://github.com/search?l=Python&q=request.is_ajax&type=Code), which isn’t 
great and isn’t reliable.”

I do this. What would the best way to handle this? Perhaps the proper practice 
should be documented when it is deprecated?

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Tom Forbes
Sent: Saturday, November 16, 2019 10:16 AM
To: django-developers@googlegroups.com
Subject: Re: Deprecate HttpRequest.is_ajax

I would agree. Flask has done the same:

DeprecationWarning: Request.is_xhr is deprecated. Given that the 
X-Requested-With header is not a part of any spec, it is not reliable

In my opinion there are not many good reasons to have to change behaviour if a 
request is made via XHR. I think the most common usage is to have a single view 
that returns a JSON response or a HTML response depending on if XHR is used 
(https://github.com/search?l=Python&q=request.is_ajax&type=Code), which isn’t 
great and isn’t reliable.



On 16 Nov 2019, at 16:08, Adam Johnson mailto:m...@adamj.eu>> 
wrote:

Django's HttpRequest.is_ajax method determines whether the request was made 
with the JS API XMLHttpRequest 
https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
 . It does so by checking the X-Requested-With header.

The new way of making "AJAX" requests from the browser is the JavaScript 
fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API .

I think the  is_ajax() documentation is at least a little misleading in 
pretending XMLHttpRequest is the only JS API. There also aren't any special 
headers set by fetch() so it's not possible to detect its requests.

I propose deprecating is_ajax() with no replacement.

Thoughts?

--
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/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups 
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es.

-- 
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/cb12b0005c5e4191be3a97d0d2c44cc5%40iss2.ISS.LOCAL.

RE: declarative settings

[Matthew Pava]

It's an interesting idea, and I'm not opposed to it myself; however, keeping 
the settings as Python code is not an abnormal practice compared to other 
software.

I've been working with some Drupal stuff lately, and it is written in PHP. 
Drupal is a content management system that can be extended with various modules 
written in PHP. It's settings file is also just a code file of PHP. Drupal does 
take advantage of a package manger called composer, which would be similar to 
our pipenv. Both of those managers use JSON files for their appropriate 
settings. But package managers are not frameworks.

Perhaps we could set up a hybrid in which we have a declarative settings file 
that can be utilized by a coded settings file, but I feel that might make the 
whole system a bit too complex to maintain.

Just my thoughts.

-Original Message-
From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Christian González
Sent: Monday, December 30, 2019 4:46 PM
To: django-developers
Subject: declarative settings

Hello,

I recently "finished" my first really working version of GDAPS, my Generic 
Django Application Plugin System. It's noway perfect, but does what it should: 
providing pluggable apps for an app framework, including a more or less 
flexible frontend with each django app.

I had much struggle with it, and one of the lessons I learned was Django's 
setup system, and how it deals with loading apps. Unfortunately Django can't 
load/unload apps on the fly, so it is necessary to restart Django whenever a 
new GDAPS app is installed via pip.

But: I want to resurrect an old theme again which would, in a way, improve some 
of the loading problems I encountered. Django's settings are code. Which is, in 
fact, a very good thing, as it makes it extremely flexible and adaptable to 
different setups. But, as discussed with the SECRET_KEY here, some of the 
settings _have_ to be coded very complicated, and it makes some things like 
per-app-settings extremely uncomfortable.

What if - and please don't kill me instantly - yes, I am a newcomer, and not a 
good programmer maybe - but some things are viewed better from "outside" - what 
if Django settings could be "declarative"?

So instead of Python code like

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes'
]

This would be in an e.g. JSON file

{

    "INSTALLED_APPS": [
        "django.contrib.admin",
        "django.contrib.auth",
        "django.contrib.contenttypes"
    ] ,
    ROOT_URLCONF: "fooproject.urls"
}

Django's settings.py would look different: It would load that settings.json 
file and set the appropriate values into local code - so this wouldn't make 
much difference.

Except 2 things:

1. Apps could have (default) settings, and they could be merged MUCH easier. 
Things like namespaced classes that are overwriting values like DRF/graphene 
does, would be completely unnecessary. The main settings.json file could be the 
"last word" in the process of settings, so anything an app would suggest could 
be overrided in the main file.

2. Installed apps could be managed much more comfortable. Adding an app could 
be done by a script (JSON editing is easy. Editing code
(=settings.py) is error prone and uncomfortable). I have a Django command 
script ATM for that, but just because I add a line into settings.py to add some 
additional apps to the list.

This even could be done with backwards compatibility, because Django would keep 
it's settings.py file optionally:

* read json settings (if they exist), use them
* load settings.py which allows to override them again (using some special code 
tricks like dynamic loading, environments etc.)

Please tell me what you think about that.

Christian


--
Dr. Christian González
https://nerdocs.at

--
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/3047a7b6-3fa0-d574-4bb6-7842b7aed44a%40nerdocs.at.

-- 
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/8ea6a5cda5f64ff6babaaf3e42fa9629%40iss2.ISS.LOCAL.

RE: Proposal: Multiple-Inheritance in Templates

[Matthew Pava]

In your example, you could just inherit from generic-list.html since it already 
extends base.html. You would be repeating yourself in your current example.

orders/list.html

{% extends 'generic-list.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}


From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Yo-Yo Ma
Sent: Sunday, February 16, 2020 10:02 AM
To: Django developers (Contributions to Django itself)
Subject: Proposal: Multiple-Inheritance in Templates

Please read this in full - you will not be disappointed by the end.

We often talk about "multiple-inheritance" when referring to multiple levels of 
{% extends ... %} and defining {% block ... %} many layers up in base templates.

But, something that comes up as a useful idea in my mind on a regular basis 
when working in Django templates is the ability to actually inherit from 
multiple base templates.

The immediate reaction to this idea might be repulsion until you think through 
the implications and weigh them against the benefits.

An example (simplified) use case speaks louder than explanation:

base.html

Some top-level menu
{% block submenu %}{% endblock %}
{% block content %}{% endblock %}

--

orders/base.html

{% extends 'base.html' %}

{% block submenu %}
View all Orders
Enter an Order
{% endblock %}

--

products/base.html

{% extends 'base.html' %}

{% block submenu %}
View all Products
Create a Product
{% endblock %}

--

So, we have a relatively common template setup, with some apps defining their 
own base templates that extend the main base template, and then defining their 
own submenus, etc.

At this point, we know there will be a product list page and an order list 
page, but we also know that the product list template will extend the product 
base template and the order list template will extend the order base template; 
same goes for the product create and order create, both also extending their 
respective apps' base templates.

This means duplication. The product list template will contain most of the same 
list-related HTML, etc. as the order list, but the only way to avoid that 
duplication will be to make a base list template and extend that template from 
both the product list and order list.

generic-list.html

{% extends 'base.html' %}

{% block content %}

{% for object in page.object_list %}
{% block list-item %}
{{ object }}
{% endblock %}
{% endfor %}

{% endblock %}

--

But, in this case we lose the benefit of the product base and order base (the 
submenus they define). Submenus are a super simplified example, but in reality 
there may be *many* different things about a given app's base template, making 
it a dilemma, or simply removing the practical ability to subclass a "generic 
list" template altogether.

Introducing multiple-inheritance:

orders/list.html

{% extends 'generic-list.html 'orders/base.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}

--


products/list.html

{% extends 'generic-list.html 'products/base.html' %}

{% block list-item %}
Product # {{ product.id }} (price: {{ product.price }})
{% endblock %}

--

The order of the templates would define the order of block definition and 
override precedence, from left to right (similar to Python class MRO).

You can also see, by the overriding of the "list-item" block, that there are 
other benefits of using extension like this, compared to e.g., defining a list 
template as an include, as a workaround.

Each template in the list would need to extend from template at the very right, 
meaning that each template left of the main template would essentially be a 
mixin. This would solve the very real problem of making generic bases for types 
of templates (list, detail, form, etc.) in your app, while still preserving the 
benefits of extension (block overrides) to all other facets of your final 
templates (vs having to use includes).
--
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/cc068a12-04ee-481a-81e1-919ed958c688%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://g

RE: Proposal: Multiple-Inheritance in Templates

[Matthew Pava]

I did read your post, and I did come to that conclusion. I may have ultimately 
misunderstood, and I’ll certainly take the blame for my own misunderstanding. 
The example you provided can be done without multiple template inheritance. So 
far, my thoughts on the design concept is that multiple template inheritance is 
unnecessary.

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Yo-Yo Ma
Sent: Tuesday, February 18, 2020 2:25 PM
To: Django developers (Contributions to Django itself)
Subject: Re: Proposal: Multiple-Inheritance in Templates

@matthew.pava please read the entire OP again.

You can't have actually read the post and come to the conclusion that 
inheriting from generic-list.html would solve the problem.

These kinds of "I didn't read it but it looks like you could just X" replies 
are a big problem in mailing lists; they have the unintended consequence of 
causing serious posts to like noobie "help me" questions by later passers by.

I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, and I 
think this feature could be a tremendous benefit to Django templates, and I'd 
like some real thoughts on the design concept.

On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
In your example, you could just inherit from generic-list.html since it already 
extends base.html. You would be repeating yourself in your current example.

orders/list.html

{% extends 'generic-list.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}


From: django-d...@googlegroups.com 
[mailto:django-d...@googlegroups.com] On Behalf Of Yo-Yo Ma
Sent: Sunday, February 16, 2020 10:02 AM
To: Django developers (Contributions to Django itself)
Subject: Proposal: Multiple-Inheritance in Templates

Please read this in full - you will not be disappointed by the end.

We often talk about "multiple-inheritance" when referring to multiple levels of 
{% extends ... %} and defining {% block ... %} many layers up in base templates.

But, something that comes up as a useful idea in my mind on a regular basis 
when working in Django templates is the ability to actually inherit from 
multiple base templates.

The immediate reaction to this idea might be repulsion until you think through 
the implications and weigh them against the benefits.

An example (simplified) use case speaks louder than explanation:

base.html

Some top-level menu
{% block submenu %}{% endblock %}
{% block content %}{% endblock %}

--

orders/base.html

{% extends 'base.html' %}

{% block submenu %}
View all Orders
Enter an Order
{% endblock %}

--

products/base.html

{% extends 'base.html' %}

{% block submenu %}
View all Products
Create a Product
{% endblock %}

--

So, we have a relatively common template setup, with some apps defining their 
own base templates that extend the main base template, and then defining their 
own submenus, etc.

At this point, we know there will be a product list page and an order list 
page, but we also know that the product list template will extend the product 
base template and the order list template will extend the order base template; 
same goes for the product create and order create, both also extending their 
respective apps' base templates.

This means duplication. The product list template will contain most of the same 
list-related HTML, etc. as the order list, but the only way to avoid that 
duplication will be to make a base list template and extend that template from 
both the product list and order list.

generic-list.html

{% extends 'base.html' %}

{% block content %}

{% for object in page.object_list %}
{% block list-item %}
{{ object }}
{% endblock %}
{% endfor %}

{% endblock %}

--

But, in this case we lose the benefit of the product base and order base (the 
submenus they define). Submenus are a super simplified example, but in reality 
there may be *many* different things about a given app's base template, making 
it a dilemma, or simply removing the practical ability to subclass a "generic 
list" template altogether.

Introducing multiple-inheritance:

orders/list.html

{% extends 'generic-list.html 'orders/base.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}

--


products/list.html

{% extends 'generic-list.html 'products/base.html' %}

{% block list-item %}
Product # {{ product.id }} (price: {{ product.price 
}})
{% endblock %}

--

The order of the templates would define the order of block definition and 
override precedence, from left to right (similar to Python class MRO).

You can also see, by the overriding of the "list-item" block, that there are 
other benefits of using extension like this, compared to e.g., defining a list 
template as an include, as a workaround.

Each template in the list would need to extend fro

RE: Subquery join support

[Matthew Pava]

It is my opinion that the Subquery object that already exists in Django should 
act as a CTE.
There is a ticket for this feature already:
https://code.djangoproject.com/ticket/28919

I have noticed that several developers have proposed several different patches 
for CTEs, but I do not know why they have never made it in. Perhaps someone 
with more knowledge on that matter can help.

From: django-developers@googlegroups.com  
On Behalf Of Alexandr Tatarinov
Sent: Monday, April 6, 2020 3:22 AM
To: Django developers (Contributions to Django itself) 

Subject: Subquery join support

Hello folks,

Following the discussion 
https://groups.google.com/forum/#!topic/django-developers/b370mxfKCHg, I would 
like to suggest adding the ability to join QuerySet with a subquery clause to 
Django.
The benefits are pretty much described and discussed in the linked topic, the 
only one I would like to add (my use case) is the ability to select multiple 
columns from a Subquery without the need to repeat the subquery clause, which 
hurts performance.
As Anssi Kääriäinen mentioned, generic subquery supports seems to be a better 
idea than CTEs, and simple implementation as a starting point will allow moving 
gradually and add RETURNING support later on (for nested creates and updates).

I have created a working prototype and successfully using it in one of my 
projects in production. After reading Daniel Miller's 
https://github.com/dimagi/django-cte, I've rewritten the API inspired by his 
ideas, plus tried to keep it as Django-style as possible.
Here is the usage example.

taxes = JoinedSubquery(Tax.objects.all())
products = Product.objects.all()

# .join is probably better be placed in QuerySet class, so it will be 
products.join(taxes, ...)
products_with_taxes = taxes.join(
products,
join_type=LOUTER,  # Optional argument, LOUTER by default
country=taxes.F('product_country'),  # Also Q objects are supported
type=taxes.F('product_type')
).annotate(
tax_amount=taxes.F('amount')  # .join() and .annotate() calls needn't to be 
chained
)

I am not sure about named joins discussed in the CTE topic
qs.attach(q1=some_qs).filter(a=F('q1__b'))

It seems to be more implicit and harder to implement, requiring changes to 
existing functionality and thus introducing a big patch which I would like to 
avoid.

It is not possible to follow relations in join.F expressions, but it is easily 
achievable by firstly fetching needed columns by annotate(), so I don't see the 
need to implement it.

Source code is available here 
https://gist.github.com/tatarinov1997/126c49c4b1bb44ae6c57afbc5f43f58d , tested 
with Django 2.2. Feel free to copy and play around.

So, please let me know what do you think about it. I am willing to continue 
working on it, and any help is appreciated.

Thanks,
Alexandr.
--
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/8c41e40f-876c-46c0-9e24-09e8c72592ce%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/1a5ac0adfa6a4b2a98b1a7862a6a2246%40iss2.ISS.LOCAL.

RE: Django default input validation accepts special caracters

[Matthew Pava]

Thank you so much for sharing that, Adam. I’ve always wondered what the best 
way was to deal with names. The systems I work with should be able to handle 
names from all countries of the world. I find you kalzumeus link only slightly 
helpful, though. It explains what we shouldn’t do. I’d rather just have an 
explanation of what we should do to handle names. Seriously, should we have 
just one field that a person can enter their full name? Or multiple fields?

And perhaps Django should lead on this. As bad as the backwards compatibility 
concerns are, we should probably just address it once and for all.

From: django-developers@googlegroups.com  
On Behalf Of Adam Johnson
Sent: Tuesday, August 18, 2020 4:26 AM
To: django-developers@googlegroups.com
Subject: Re: Django default input validation accepts special caracters

I am against adding validation here. See the classic Falsehoods Programmers 
Believe About Names: 
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
 .

Here are some characters that have caused security issues in the past (e.g. URL 
bar display), but I'd reckon are legitimate in some human names:

  *   non-breaking space
  *   zero-width space
  *   RTL or LTR markers
  *   Quote marks
If you do want to block this, we don't need a new argument to Charfield. You 
can implement a custom validator, and even pair it with a database constraint. 
But you might block legitimate users.

The only change we should be making is moving from separate first_name + 
last_name fields to solely a name field, since *many* people don't fit into 
that. I think there's a ticket, but there are massive backwards compatibility 
concerns.

P.S. never forget the case of Mr Null: 
https://www.wired.com/2015/11/null/

On Tue, 18 Aug 2020 at 09:39, Kacper Szmigiel 
mailto:szmigielkac...@gmail.com>> wrote:
Hello!

Maybe some `special_characters` bool field on models.CharField with default to 
`False` would do the job?

wt., 18 sie 2020 o 10:36 '1337 Shadow Hacker' via Django developers 
(Contributions to Django itself) 
mailto:django-developers@googlegroups.com>> 
napisał(a):
Currently, when you order a security audit on a Django project from any of the 
firms I've seen so far (including my own), all inputs fall short on stuff like:

"First name input: allows special caracters such as <>/"' which may cause a 
security issue with further developments done on the same database but outside 
Django".

As far as I can imagine, special caracters would be acceptable on inputs that 
should accept code or some kind of math, which is not the case for most inputs.

Django should harden default input validation to make it easier for Django 
projects to get a good grade on security audits, without having to go over all 
fields to setup basic input validators.
--
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/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.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/CAFfZ%2Bb4GNSksSUm%3De8bQAp1t1qgDkLvNpitYjLmY1QHb94vs7w%40mail.gmail.com

RE: Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

[Matthew Pava]

The filter states that it expects plain text. In Python, str(None) = "None". To 
get the behavior you are seeking use the default_if_none filter, and chain your 
other filters.
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#default-if-none
{{ text|default_if_none:""|linebreaksbr }}

-Original Message-
From: django-developers@googlegroups.com  
On Behalf Of Carles Pina i Estany
Sent: Monday, September 14, 2020 2:40 PM
To: django-developers@googlegroups.com
Subject: Incomplete documentation or bug? (linebreaksbr and stringfilter 
decorated filters)


Hi,

Today I had a small surprise with templates and the linebreakbr filter.

The "problem" (or root of the confusion) is that if None (of NoneType) is given
to linebreakbr it returns a SafeString 'None' instead of None (type NoneType).

The documentation says 
(https://us-east-2.protection.sophos.com?d=djangoproject.com&u=aHR0cHM6Ly9kb2NzLmRqYW5nb3Byb2plY3QuY29tL2VuLzMuMS9yZWYvdGVtcGxhdGVzL2J1aWx0aW5zLyNzdGQ6dGVtcGxhdGVmaWx0ZXItbGluZWJyZWFrcw==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=eTYyb1Foa2VZVFJhdVU5dVBQazhvVFMycUpCMnZHSTFkZW9IOThqYVowWT0=&h=805589589ba040129c546a8f291d13ac):
"""
Replaces line breaks in plain text with appropriate HTML; a single newline
becomes an HTML line break () and a new line followed by a blank line
becomes a paragraph break ().
"""

Passing a None to linebreaksbr I was expecting to receive None. I read it
literally that it would add line breaks in plain text and if there was no plain
text then nothing would be done. Or at least if None is passed it would 
return None.

For example:
{% with text=None %}
{% if text %}{{ text }}{% else %}-{% endif %}
{% endwith %}

{% with text=None|linebreaksbr %}
{% if text %}{{ text }}{% else %}-{% endif %}
{% endwith %}

The second block prints "None" instead of "-".

The None gets converted to the string in the decorator 'stringfilter'.
The same happens in addslashes, capfirst, etc.

Should this be noted in the documentation? Or the behaviour changed? (hard
without backward compatibility issues). Or have I missed anything? Any
thoughts?

(I've checked the Django bug tracker and I haven't seen any bug describing
this)

Cheers,

-- 
Carles Pina i Estany
https://us-east-2.protection.sophos.com?d=pina.cat&u=aHR0cHM6Ly9jYXJsZXMucGluYS5jYXQ=&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=QUNiOTdmclhvZW9UZm4reEtEaExwOE9hM05Vc1dQN3VIc1ZISUtjWm1UQT0=&h=805589589ba040129c546a8f291d13ac

-- 
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://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzIwMjAwOTE0MTk0MDE0LkdBMTkwMDclNDBwaW5hLmNhdA==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=MkRHTjRCUitxY0NPeUVSbmlRQi9ZMHRwclIrVFNhQ1lNTXlrQ1FSeGswRT0=&h=805589589ba040129c546a8f291d13ac.

-- 
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/b888ccf136b7465b9bf7863e7a423945%40iss2.ISS.LOCAL.

RE: Difference between AdminSite.admin_view and staff_member_required?

[Matthew Pava]

> Thoughts on deprecating it?
It seems like a good idea. However, it leads us to another question. Do we 
really need the is_staff field on the User Model if it is deprecated?

From: django-developers@googlegroups.com  
On Behalf Of Timothy McCurrach
Sent: Tuesday, March 9, 2021 3:22 PM
To: django-developers@googlegroups.com
Subject: Re: Difference between AdminSite.admin_view and staff_member_required?

staff_member_required feels like a bit of a relic from the past:

- It looks like before a massive refactor of the admin that happened 12 years 
ago 
(https://github.com/django/django/commit/a19ed8aea395e8e07164ff7d85bd7dff2f24edca)
 staff_member_required played a similar role to what Adminsite.admin_view does 
now (checks permissions and redirects to login if appropriate). Before the 
refactor, all of the relevant views were wrapped with staff_member_required.
- The above commit introduced AdminSite which has its own 'has_permissions' 
method. Adminsite.root (which was the old get_urls) called self.has_permissions 
before calling any other views, so staff_member_required was now no longer 
really required.
- staff_member_required did however continue to be used in the admindocs app 
(which was now split off into its own app).
- Adminsite.root was eventually replaced with get_urls and the call to 
has_permissions  was moved into `Adminsite.admin_view` (which also does a few 
other things: adds csrf protection, and deals with caching)
- Over time staff_member_required became simpler and simpler as things like 
user_passes_test were introduced, and there was no need to repeat logic.
- It's now just a very specific version of `user_passes_test` and is only used 
internally one place - the admindocs app.


Tobias - In terms of permissions and redirecting; the behaviour of admin_view 
and `staff_member_required` are very similar. The differences are that:
 i) admin_view defers to Adminsite.has_permission to do the actual checking of 
permissions (so if that method is overwritten the behaviour will change)
 ii) admin_view does a whole load of other things that all admin views are 
going to need (mentioned above).
 iii) They have slightly different arguments you can pass in to modify the 
behaviour

If you are decorating a view of ModelAdmin, or AdminSite you should use 
admin_view - as described in the docs under get_urls.

Since staff_member_required is more or less a very specific version of 
user_passes_test designed for admin views, it's use-case seems pretty niche. If 
you were making an app like admindocs which behaves like an extension of the 
admin app, without actually being part of the admin app you could use it then, 
but I'm struggling to think of any other time you would want to use it though.

I think there's an argument to be made for deprecating it completely:
 - It's only used in one place internally, and the wider use case seems pretty 
niche.
 - user_passes_test can do the same thing and seems to be the standard way of 
doing this kind of thing anyway.
 - user_passes_test with a suitably named test argument would also be more 
explicit, since the login_url and redirect_field_name would need to be 
explicitly stated.

 Definitely the documentation should be updated though. Thoughts on deprecating 
it?

Tim

On Tue, Mar 9, 2021 at 7:08 PM Tobias Bengfort 
mailto:tobias.bengf...@posteo.de>> wrote:
On 09/03/2021 18.03, Carlton Gibson wrote:
> Do you want to open a PR with suggested changes as a focus for discussion?

I would open a PR that improves the docs, but I still don't understand
the difference, so I wouldn't know what to write.

The other alternative would be remove one of them, but at this point
that is probably too drastic.

tobias

--
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/d10799d4-8a42-6caa-8e13-c2ce93256521%40posteo.de.
--
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 rece

Re: Do people actually squash migrations?

[Matthew Pava]

I've had similar issues. I just avoid squashing anymore. It's just not with the 
pain, and having so many little files that get looked at a minimal amount of 
time isn't worth fretting over. Saying that, I'd love to get it fixed...

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android


From: 'Mike Lissner' via Django developers (Contributions to Django itself) 

Sent: Tuesday, May 11, 2021 7:50:31 PM
To: Django developers (Contributions to Django itself) 

Subject: Do people actually squash migrations?

I have a pretty big django project, and since I created the 100th migration 
within one of its apps today, I thought I'd finally do some squashing. It 
hasn't gone well, but I eventually got the data migrations cleaned up.

Finally, I run it, and it runs smack into a CircularDependencyError, as 
described here:

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

Basically, from what I understand, after the squash you have one migration that 
depends on various others from your other apps. Naturally, that totally falls 
over, because can't go from this series of migrations:

app1: migration 1
app2: migration 1
app2: migration 2
app1: migration 2

To, well...any series of migrations in which migration 1&2 from app1 or app2 
have been squashed. The docs have something to say about this*, but it feels 
like this must affect practically any biggish project.

Stackoverflow also has a variety of dubious (and very complex) advice (read it 
and weep):

https://stackoverflow.com/questions/37711402/circular-dependency-when-squashing-django-migrations

So, my question is: Do people actually use squashmigrations with success? And 
if not, is it reasonable to consider deprecating it or fixing the bug, or 
updating the docs to loudly say it largely doesn't work? I'm surprised the 
issue above has so little movement since it was created seven years ago.

Maybe it's just me? If not, it'd be nice to do something to help future people 
with ambitions of a simple squash.

Thanks,


Mike

* Note that model interdependencies in Django can get very complex, and 
squashing may result in migrations that do not run; either mis-optimized (in 
which case you can try again with --no-optimize, though you should also report 
an issue), or with a CircularDependencyError, in which case you can manually 
resolve it.

To manually resolve a CircularDependencyError, break out one of the ForeignKeys 
in the circular dependency loop into a separate migration, and move the 
dependency on the other app with it. If you’re unsure, see how 
makemigrations
 deals with the problem when asked to create brand new migrations from your 
models. In a future release of Django, 
squashmigrations
 will be updated to attempt to resolve these errors itself. [Author's note: 
These sentences really leave me blowing in the wind...maybe I can figure out 
what they mean, I guess? I thought squashing was supposed to be easy.]



--
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/87f449bc-d653-427a-ac28-879ee0701c8bn%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/SN6PR05MB3951135EF4ECFE249F51ED4BF1529%40SN6PR05MB3951.namprd05.prod.outlook.com.

RE: CTRL-BREAK still make sense on Windows for `runserver`?

[Matthew Pava]

Ctrl + Break and Ctrl + C are treated slightly differently by Windows. Ctrl + 
Break is always a signal, but an application can override the functionality of 
Ctrl + C.

Please see 
https://docs.microsoft.com/en-us/windows/console/ctrl-c-and-ctrl-break-signals

I’ve dealt with this issue many times in the past (in other applications) in 
which I tried Ctrl + C but got nowhere. As such, I prefer the current behavior.

Your Surface 4 keyboard simply doesn’t have a Break or Pause key. Either try 
getting another keyboard, use the Pause on the on screen keyboard, use a 3rd 
party utility to map the keystroke, or just use Ctrl + C. Many people have 
complained about this issue, but I don’t consider it a Django issue.


From: django-developers@googlegroups.com  
On Behalf Of wi...@wsvincent.com
Sent: Monday, June 21, 2021 3:10 PM
To: Django developers (Contributions to Django itself) 

Subject: CTRL-BREAK still make sense on Windows for `runserver`?

Hi all,

Is the Pause/Break key still a thing on Windows keyboards? My new Surface 4 
doesn't even have such a key and I think this applies to many new Windows 
keyboards as well.

I ask because the runserver.py command 

 currently has `CTRL-BREAK` if Windows32 or `CONTROL-C` for everything else, 
like Mac/Linux. Seems this could be just standardized to `CONTROL-C` no?

-Will
--
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/ee88cce3-3f7e-4ca8-b2af-e1bc4b1fe8c4n%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/602088ed84714747a4b095939e18cd93%40Exchange.ISS.LOCAL.

RE: Adding Support for DB Views

[Matthew Pava]

Currently, I just use the migrations to do a RunSQL and then I make a model 
with the Meta option managed set appropriately. It works for me, but perhaps 
something a bit more convenient is in order these days.

From: django-developers@googlegroups.com  
On Behalf Of Vasanth Mohan
Sent: Monday, February 21, 2022 8:21 AM
To: Django developers (Contributions to Django itself) 

Subject: Adding Support for DB Views

Are there any plans to support DB Views ? Would the team be interested in 
mainlining it if there is a PR for it ?

I tend to use DB Views on Postgres at my day job and wouldn't mind adding basic 
support across Django's supported DBs. I'll probably take inspiration from 
Knex.js
 to implement it.

I'm imagining something along the lines of,
class NewView(models.ViewModel):
 def view_qs(self):
return qs # Define with QS  to be used in CREATE VIEW 
App_ViewModel as QS;

migrations.CreateViewModel( ... )
migrations.DeleteViewModel( ... )
migrations.UpdateViewModel( ... )


--
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/e009c1bd-8a68-486a-8b7f-7c3d9e3553een%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/b5f0b99b068a4ea192797708d4f5037d%40Exchange.ISS.LOCAL.

RE: Revisiting MSSQL and Azure SQL Support in Django

[Matthew Pava]

I agree with Tim’s sentiment here. Had a solid SQL Server backend been 
available 7 or 8 years ago, I would probably have used that due to the 
requirements from my supervisor. I had to convince him that PostgreSQL would be 
just as good.

Based on what I read on the Git page, though, the backend doesn’t pass some 
tests that it seems like it ought to. Once it is better, as Tim already stated, 
I would absolutely support and wish and hope that SQL Server would become a 
part of core. It is one of the most popular database backends in use.

One argument was made that we don’t need to add any other database backends to 
core because they are doing fine as third-party dependencies. To that I would 
ask, why have any database backend in core then? Why not have them all be 
third-party dependencies?

Just my two cents,
Matthew

From: django-developers@googlegroups.com  
On Behalf Of Tim Allen
Sent: Friday, April 1, 2022 10:02 AM
To: Django developers (Contributions to Django itself) 

Subject: Re: Revisiting MSSQL and Azure SQL Support in Django

Full disclosure: I've helped maintain SQL Server Django engine packages in the 
past, and was involved in getting the project started for the official 
Microsoft Django engine package.

First, thanks to Warren and the folks from Microsoft for creating this backend. 
There are a fair amount of users that need a Microsoft SQL Server backend, and 
for years we've been having to shuttle between barely-maintained engines, 
forks, and pip installs to commit hashes while waiting for merges. It is less 
than ideal. Several big supporters of Django (The Wharton School, RedHat 
Ansible, to name two) have been among those looking for a solid backend 
solution for years. Microsoft has provided us a vastly improved option to what 
we'd been saddled with for the past decade.

The DB popularity index at db-engines.com has regularly listed the top four as 
Oracle, MySQL, Microsoft SQL Server, and PostgreSQL, in that order. I notice 
some comments in this thread about Microsoft being for-profit... well, what 
about Oracle? I don't see Oracle on the Support Django page either, yet two of 
their databases have support in core. MSSQL is the only one of the big-four 
RDBMS's without support in core Django. That seems to be a pretty big hole in 
Django's offering.

That said, I completely agree that the backend still needs work, and a solid 
commitment from Microsoft before being brought into core Django. I want to make 
sure Microsoft knows that many in our community appreciate their efforts in 
taking the lead on this backend: support for SQL Server in the Django ecosystem 
is far better than it ever has been in my eight years of being a Djangonaut. 
They have put a lot of time and effort into this project, and I think they're 
well on their way to where they need to be for the long-term goal of being in 
core Django.

A lot of the questions being asked of Microsoft in this thread just don't seem 
fair to me - we're not asking the same of Oracle, Redis Enterprise Software, or 
any of the other commercial products that Django has built-in support for. Why 
Microsoft and not the others?

Warm regards,

Tim
On Friday, April 1, 2022 at 8:39:17 AM UTC-4 Salman Mohammadi wrote:
Hi,

IMO, Django is there to create value for *its* users.

I'm not aware how MS Team reached this conclusion that merging their incomplete 
package into Django core creates more value for Django users than when it is a 
third-party package. Would you please tell me how?

I have access to only two resources to calculate the popularity of mssql-django 
package, one of them is the last Django Survey,

https://www.djangoproject.com/weblog/2022/jan/03/django-developers-survey-2021-results/

and the other one is Github Stars. None of them show any sign that MS package 
is even semi-popular among Django users.

We have many popular packages that are residing outside of Django core and 
living happily their lives.

Probably MS wants to use this merge as a marketing point for their MSSQL, a 
proprietary software.

At the end I, as a total outsider with no direct connection of any kind with 
Django project, have nothing against merging MS package into core the same way 
that we have Oracle backend. But before that, there are some questions that 
need to addressed:

1. How can MS package create more value for Django users by getting merged into 
main branch?

2. According to your internal spying tools, how popular is your package?

3. How can you guarantee the long-term sustainability of your package?

4. What are the previous involvements of MS Package contributors in Django?

5. How does MS support Django Project for its 

RE: How Django inlineformsets works internally

[Matthew Pava]

You might want to look at stuff that has already been developed.  (No need to 
reinvent the wheel, right?)
Check out this jQuery plugin for making a dynamic formset:
https://github.com/elo80ka/django-dynamic-formset

You might find some answers there.

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of sevenrrain...@gmail.com
Sent: Friday, October 13, 2017 7:59 AM
To: Django developers (Contributions to Django itself)
Subject: How Django inlineformsets works internally

Hello,

First I know, this is for django developers, but I asked on django-users, 
stackoverflow, udemy etc and I never got an answered, so this is my last 
options, to ask the developers.

I checked the Django code for BaseFormset, 
modelform_factory,modelformset_factory,formset_factory etc but not everything 
is clear for me.

-

I have a form with two inline formsets.
.

At the HTML level Django use the hidden fields for the formset management, and 
use the prefix to know which fields are related to a formset.

Also it has ids in the html id, to group like in a virtual form the fields.









On retrieve by default I get the path to the file in a paragraph and the inputs 
(html elements) are empty.



 Currently:
Test 
Insieme/documents/sdsasa7

Change:




On Browse(upload a different file) Django knows to update the same record in 
the database. Similar for click on checkbox.



How Django make the correlation between the paragraph that show the path, the 
html id of the element and what is in the database?



I want to change the UI (make it dynamic with JavaScript, use button instead of 
checkbox for delete) and I want to understand how the mechanism is working 
because I need to do two very customize formsets.



Thank you!
--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e8690a9c-a8b8-4cab-bc64-7ff01f36ff8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8fc8458b364241ff8ffe94b8ca029b32%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: #28788: Add support for Model.clean_

[Matthew Pava]

I don’t use Field.validators much myself, but it seems that the Form clean 
method also calls Field.validators, so the redundancy is already there in the 
Form class.  For consistency’s sake, I suggest we either add 
Model.clean_fieldname(), or we remove Form.clean_fieldname().  Both suggestions 
would certainly have issues with backwards compatibility.

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Jonas Haag
Sent: Thursday, November 9, 2017 4:04 AM
To: django-developers@googlegroups.com
Subject: #28788: Add support for Model.clean_

Hi,

I’m taking https://code.djangoproject.com/ticket/28788 to this mailing as per 
Tim’s request.

I’m convinced we should add a Model.clean_ method, the model 
equivalent to Form.clean_.

Form validation has forms.Field.validators, Form.clean, and 
Form.clean_.
Model validation has models.Field.validators, Model.clean, but no 
Model.clean_.

Using Field.validators works, but is cumbersome and inelegant as you’ll have to 
put model validation logic outside the model definition.

Model.clean_ also helps you structure your validation logic, 
particularly if subclasses are involved.

Backwards compatibility is an issue with my suggestion that is yet to be 
solved. We don’t want surprising calls to clean_XXX methods that were defined 
before this feature was introduced.

I’m curious to hear what everyone else thinks!

Jonas
--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D7A48F7D-0A60-4ADF-B210-F73FA1F0B717%40lophus.org.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/42e405c8d5454699a09bea9960cc1c8d%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: models.CalculatedField feature

[Matthew Pava]

I handle that situation quite differently.
I have a model manager that annotates different fields to the queryset 
depending on when I need them.
For your example, I would have something like this:


class CustomerQuerySet(models.QuerySet):
   def with_allowed_to_drink(self):
  return self.annotate(allowed_to_drink=Case(When(age__gte=18, then=True), 
default=False))


Then I actually created a decorator that applies the manager to instances on a 
model.  It is not as generic as it could be since it depends on function names 
having the word “with” in them, but I’m sure we could make it more general.
def queryset_on_instance(model: Model):
"""Takes the queryset of a model and creates new properties for each 
instance of the model based on
the custom queryset class.  Some code is copied from 
django.models.managers; most of this was inspired by it.
The queryset methods that are copied must have 'with' in their name.

Tip: Use this as a decorator on model classes
"""

def create_method(method_name):
def the_method(self):
return getattr(model._default_manager, 
method_name)().get(pk=self.pk)

return the_method

queryset_class = getattr(model._default_manager, "_queryset_class", None)
predicate = inspect.isfunction
for name, method in inspect.getmembers(queryset_class, predicate=predicate):
if 'with' in name:
# Only copy missing attributes.
if hasattr(model, name):
continue
# Only copy public methods or methods with the attribute 
`queryset_only=False`.
queryset_only = getattr(method, 'queryset_only', None)
if queryset_only or (queryset_only is None and 
name.startswith('_')):
continue
# Copy the method onto the model.
setattr(model, name, create_method(name))
return model


And then on your Customer model:

@queryset_on_instance
class Customer(models.Model):
   age = models.IntegerField()
   objects = CustomerQuerySet.as_manager()


In your code or template, you would access the value like so:
customer.with_allowed_to_drink.allowed_to_drink

And you can filter by the value like so:
Customers.objects.with_allowed_to_drink().filter(allowed_to_drink=True)

I do agree that it would be nice to have something out of the box that could 
handle custom properties in the QuerySet calls, or, as you put it, calculated 
fields.


From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of 
ilya.kazakev...@jetbrains.com
Sent: Wednesday, November 15, 2017 7:21 AM
To: Django developers (Contributions to Django itself)
Subject: models.CalculatedField feature

Hello.

I think I just invented very useful feature.
I have the following model

class Customer(models.Model):
age = models.IntegerField()

I want to show special link in template for customer if she is allowed to drink.

class Customer(models.Model):
age = models.IntegerField()

@property
def allowed_to_drink(self):
return self.age >= 18

And in template I can do

{% if customer.allowed_to_drink %}.

But in another view I want to show only those customers, who are allowed to 
drink.
So, in view I write

drinkers = [customer for customer in models.Customer.objects.all() if 
customer.allowed_to_drink].

But what if I have one million customers? It is insane to check this field on 
Python side instead of database side.
I use ORM:
models.Customer.objects.filter(age__gte=18).all()

And DRY principle is now violated.
See, I have knowledge "allowed_to_drink -> (age >= 18) " and I want to write in 
once, and then use both in ORM queries and object method.

And I am not alone here:
https://stackoverflow.com/questions/31658793/django-filter-query-on-with-property-fields-automatically-calculated
https://stackoverflow.com/questions/2143438/is-it-possible-to-reference-a-property-using-djangos-queryset-values-list

Here is what I suggest

class Customer(models.Model):
age = models.IntegerField()
allowed_to_drink = models.CalculatedField(Q(age__gte=18))

# Using in ORM
Customer.objects.filter(allowed_to_drink=True)
# It actually converted to
Customer.objects.filter(Q(age__gte=18))

# Using it in code
Customer().allowed_to_drink
# This part a little bit tricky, since you will need to check in on Python side.
# "age__gte" should be converted to
funcs = {
"gte": lambda instance, field, value: getattr(instance, field) >= value
}
instance_field, func = "age__gte".split("__")
funcs[func](instance, instance_field, 18)

But we already have code to convert Q to SQL, so it should be easy to do it for 
python.

Some more ideas:
*  "Q" may have lazy evalutation here for cases like 
"models.CalculatedField(Q(date__gte=now()))". Could be implemented with 
lambdas, or we can simply allow only literal here.
* With Postrges you can even store calculated field in database (it has 
calculated column), but it works only for literals.

I th

RE: Additional PostgreSQL-specific functions

[Matthew Pava]

I wonder if we should put that in this ticket:
https://code.djangoproject.com/ticket/28643


From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Joey Wilhelm
Sent: Friday, November 17, 2017 2:02 PM
To: django-developers@googlegroups.com
Subject: Additional PostgreSQL-specific functions

Greetings,

Yesterday I opened a ticket[1] for a "RegexpReplace" method for PostgreSQL. 
After some talk and encouragement over in IRC, I have additionally created a 
"SubstrFrom" function for PostgreSQL, which allows you to use a regex match in 
order to extract your substring.

So at this point, I have a couple of questions.

1) Are these things which would likely get integrated into core?
2) If so, should I put them into separate tickets or would I be able to combine 
them into a single?
3) Should they be added to the PostgreSQL specific library? Oracle does have 
both of these pieces of functionality, but I believe it is the only popular 
engine aside from PostgreSQL which does.

I have the code for both of these implemented in my local project, along with 
tests, so I would love to contribute them if possible.

Thank you!


[1]: https://code.djangoproject.com/ticket/28805
--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADBkHd%2Be3GodbKvDFXq0dAgwzs4n%3DFgLGHTYsbhuiQWDOcB64Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

Re: PostgreSQL aggregation and views through unmanaged models

[Matthew Pava]

You asked me to join in on this conversation as I had an issue using Django 
1.11.  My third party apps do not yet all support Django 2.0.

I have an unmanaged model that is connected to a view in PostgreSQL.  I 
attempted to create an annotated version of the model manager using the 
.annotate() method.  Unfortunately, I am getting an error that some fields 
“must appear in the GROUP BY clause or be used in an aggregate function.”  
It was a mysterious error message for me.

 

Upon further investigation, it appears that I need a PRIMARY KEY in the 
backend to avoid having to include columns in a GROUP BY clause, but 
PostgreSQL does not allow for such constraints to be added to a VIEW.  The 
“id” column is just a row_number().

On Sunday, May 21, 2017 at 10:05:38 PM UTC-5, charettes wrote:
>
> Hello fellow developers,
>
> As some of you may know PostgreSQL 9.1 added support for GROUP'ing BY
> selected table primary keys[0] only. Five years ago it was reported[1] that
> Django could rely on this feature to speed up aggregation on models backed
> up by tables with either many fields or a few large ones.
>
> Being affected by this slow down myself I decided to dive into the ORM 
> internals
> and managed to get a patch that made it in 1.9[2] thanks to Anssi's and 
> Josh's
> review[3].
>
> One subtle thing I didn't know back in the time is that PostgreSQL query 
> planner
> isn't able to introspect database views columns' functional dependency 
> like it
> does with tables and thus prevents the primary key GROUP'ing optimization 
> from
> being used.
>
> While Django doesn't support database views officially it documents that
> unmanaged models can be used to query them[4] and thereby perform 
> aggregation on
> them and generating an invalid query.
>
> This was initially reported as a crashing bug 9 months ago[5] and the 
> consensus
> at this time was that it was an esoteric edge case since there was few 
> reports
> of breakages and it went off my radar. Fast-forward to a month ago, this is
> reported again[6] and it takes the reporter quite a lot of effort to 
> determine
> the origin of the issue, pushing me to come up with a solution as I 
> introduced
> this behavior.
>
> Before Claude makes me realize this is a duplicate of the former report 
> (which I
> completely forgot about in the mean time) I implement a patch and commit 
> it once
> it's reviewed [7].
>
> When I closed the initial ticket as "fixed" the reporter brought to my 
> attention
> that this was now introducing a performance regression for unmanaged models
> relying on aggregation and that we should document how to disable this
> optimization by creating a backend subclass as a workaround instead.
>
> In my opinion the current situation is as follow. The optimization 
> introduced a
> break in backward compatibility in 1.9 as we've always documented that 
> database
> views could be queried against using unmanaged models. If this issue had 
> been
> discovered during the 1.9 release cycle it would have been eligible for a
> backport because it was a bug in a newly introduced feature. Turning this
> optimization off for unmanaged models by assuming they could be views is 
> only
> going to degrade performance of queries using unmanaged models to perform
> aggregation on tables with either a large number of columns or large 
> columns
> using PostgreSQL.
>
> Therefore I'd favor we keep the current adjustment in the master branch as 
> it
> restores backward compatibility but I don't have strong feelings about 
> reverting
> it either if it's deemed inappropriate.
>
> Another solution I came up while writing this post would be to replace the
> feature flag by a callable that takes a model as a single parameter and 
> returns
> whether or not the optimization can be performed against it. The default
> implementation would return `mode._meta.managed` but it would make it 
> easier for
> users affected by this to override in order to opt-in or out based on their
> application logic.
>
> Thank you for your time,
> Simon
>
> [0] https://www.postgresql.org/docs/9.1/static/sql-select.html#SQL-GROUPBY
> [1] https://code.djangoproject.com/ticket/19259
> [2] 
> https://github.com/django/django/commit/dc27f3ee0c3eb9bb17d6cb764788eeaf73a371d7
> [3] https://github.com/django/django/pull/4397
> [4] https://docs.djangoproject.com/en/1.11/ref/models/options/#managed
> [5] https://code.djangoproject.com/ticket/27241
> [6] https://code.djangoproject.com/ticket/28107
> [7] 
> https://github.com/django/django/commit/daf2bd3efe53cbfc1c9fd00222b8315708023792
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django

PR 9583 - Ticket 28643

[Matthew Pava]

Hi everyone,
I've been working on ticket 28643 specifically adding Ord, Chr, Left, and Right 
to Django's built-in database functions.  I've done the PR #9583.  I am a new 
contributor, and I've never really contributed code to any project through pull 
requests ever before.  I appreciate your guidance.  The checks have passed, and 
I've got a mess of commits that I've tried to squash a couple of times but seem 
to stick around nonetheless.

I also made a comment on the ticket that maybe instead of using Left, Right, 
and Substr functions that we instead implement slicing on fields and 
expressions to make things more pythonic (and deprecate Left, Right, and 
Substr).  Would such an implementation need a new ticket?  And then would we 
need to consider slicing all iterables instead of just only CharFields, 
TextFields, and string expressions?

Also, most of the functions in ticket 28643 that go across all supported Django 
database backends are complete, with the exception of ROUND.  SQLite does not 
come with many built-in math functions, though there are extensions available.  
I was wondering how we should proceed with that ticket when ROUND is completed.

Thank you!

https://github.com/django/django/pull/9583
https://code.djangoproject.com/ticket/28643

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/08256bba55da406080bdc813ef776c29%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: DEP Pre-posal: Re-Designing Django Forms

[Matthew Pava]

> It includes ajax file upload which every user expects in the modern web which 
> seems to be the feature which defines feature-completion of a UI framework, 
> compared to what HTML offers out of the box.
Bandwagon logical fallacy (“every user expects”)

In my project, I have no need for file upload.  And I have no need for it in 
the foreseeable future, and, as such, I do not expect my framework to be able 
to handle it.

I’m neither supportive nor opposed to the idea of changing Django forms, but 
please avoid logical fallacies in supporting your position.


From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Saturday, February 3, 2018 6:36 PM
To: django-developers@googlegroups.com
Subject: Re: DEP Pre-posal: Re-Designing Django Forms

On Thu, Feb 1, 2018 at 12:46 PM, Marc Tamlyn 
mailto:marc.tam...@gmail.com>> wrote:
> This is a huge project to achieve everything you mentioned in your email, and 
> it has implications across a large number of Django packages (not least the 
> admin). I don't want to discourage you, but don't underestimate how much work 
> it would be to get a good replacement for forms for the modern web.

Perhaps we should just be able to swap Forms with WTForms or another python 
library and bake in ElementUI, even if that means replacing template_name with 
vue_name in the view generic class, but if we're talking about "modern web" 
then perhaps it's time for npm to become a first class citizen.

> Your next steps should be to research, spec and potentially write a DEP.

In my recent research it seemed ElementUI the most feature complete UI. It 
includes ajax file upload which every user expects in the modern web which 
seems to be the feature which defines feature-completion of a UI framework, 
compared to what HTML offers out of the box.

Thanks a lot for doing something about this Robert, forms in django definitely 
needs a major refactoring sprint, typically remove the field/widget layer and 
rely on one level inheritance that will help a lot for example with material 
design which displays field.name inside the widget, not 
possible with current object design.
--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c44115b589e94fa0b6da27854b114332%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: Shouldn't manage.py call python3 instead of python?

[Matthew Pava]

Right.  I just use python manage.py…
I just checked python3 manage.py and it doesn’t work.

From: collinmander...@gmail.com [mailto:collinmander...@gmail.com] On Behalf Of 
Collin Anderson
Sent: Wednesday, April 11, 2018 7:46 AM
To: django-developers@googlegroups.com
Subject: Re: Shouldn't manage.py call python3 instead of python?

but python3 manage.py  doesn't work on windows, right?

On Tue, Apr 10, 2018 at 10:17 PM, Josh Smeaton 
mailto:josh.smea...@gmail.com>> wrote:
As a datapoint, I've seen roughly 1 person per week in #django IRC confused 
about specific startup exceptions due to them using python 2 rather than python 
3 on Django >= 2.0. Unsure how many of these are due to the shebang. That said, 
it looks like there are no good solutions other than maybe ensuring our docs 
always show the form python3 manage.py  rather than ./manage.py 
.

On Wednesday, 11 April 2018 12:02:31 UTC+10, Bobby Mozumder wrote:
In any case you’re going to see a lot of Django 2.0 developers on Mac OS hit 
this problem when they install to default Python or use standard Python install 
convention where Python 3.5 is installed as “python3".

-bobby

On Apr 10, 2018, at 3:46 PM, Aymeric Augustin 
mailto:aymeric@polytechnique.org>> wrote:

On 10 Apr 2018, at 17:43, Florian Apolloner 
mailto:f.apo...@gmail.com>> wrote:

On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
Since `django-admin startproject my_project` is created on the fly from 
templates, couldn't we dynamically create the `manage.py` executable based on 
some system introspection and an agreed upon priority

Wouldn't that result in something along the lines of "works on my system" and 
breaks elsewhere? after all manage.py is committed into git more often than not.

... which directs us to the correct solution: setting PYTHONPATH and 
DJANGO_SETTINGS_MODULE correctly and using django-admin instead of manage.py.

pip / setuptools rewrites the shebang line appropriately when it installs the 
django-admin script. (I'm not sure how this happens exactly.)

My point is — there's no perfect solution. At best we can aim for a less 
imperfect solution than the status quo.

--
Aymeric.


--
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 post to this group, send email to 
django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/C36A8494-1094-4A03-A402-618BB999F927%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33ec0ccb-a63b-4451-bfec-815b9e5f52a7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S6xks7eiFGWYtvvWo0E8JXaiHWOPLvVbY_T_UQHy0YURw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 em

RE: Get decorator

[Matthew Pava]

I think the idea is that some developers may have fields on their models called 
“url” or “absolute_url” and having a property by that name would cause naming 
conflicts. (Actually, I think I ran into this issue once with my own projects.) 
 Creating any property on a model in the Django core would result in potential 
naming conflicts for all the projects that are out there.  Of course, there’s 
nothing stopping you from doing it in your local project, and you may want to 
create your own custom models.Model class to inherit from and use in all of 
your models.


From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Hélio Correia
Sent: Wednesday, May 16, 2018 5:37 PM
To: Django developers (Contributions to Django itself)
Subject: Get decorator

Hi community,

I always want to ask if it's not a god idea change some get_ methods with the 
property decorator? Things like get_absolute_url for example. What are your 
thoughts about that?
--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b4d4dd2f-eaaa-4758-aa3a-22eade759fc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0cdddb7a90cf4f96b85acdf528dcc177%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: thoughts for Django fellowship applicants

[Matthew Pava]

On behalf of myself and on behalf of everyone else I speak for, thank you, Tim, 
for doing such an outstanding job with Django!

I know that I only made one contribution, and you played such an important role 
in helping me understand what I was doing wrong and how to fix it.  And I 
appreciate that to this day.  I would love to become a more consistent 
contributor, but my own lack of time prevents it.

Thank you,
Matthew Pava

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Tim Graham
Sent: Tuesday, January 8, 2019 10:45 AM
To: Django developers (Contributions to Django itself)
Subject: thoughts for Django fellowship applicants

Hello,

If you haven't seen the post*, I'll be stepping down as a Django fellow at the 
end of March. Applications are open until this Friday if you're interested in 
joining Carlton in the position.

I wanted to give a brief retrospective on some aspects of my experience, with 
the hope that it'll be helpful for the future of the program.

There are a number of reasons for my decision, but mainly I've felt a need to 
disconnect for a while and take a break. I want to explore other things besides 
computers. I don't have the same excitement for the work as when I started. 
Django development was less structured back then. It was fun to set up 
continuous integration and a regular release schedule and bring order to chaos. 
Now with those things in place, I think Django will continue to plod along just 
fine without me.

It's been tough for me to take a guilt-free vacation because there's not much 
"excess capacity" in the fellowship staffing. Even with another fellow working 
part-time, there's a backlog of review work that accumulates when a fellow 
takes a break. It's easy to feel overwhelmed when you return. Maybe this is 
fine. If the fellowship were overstaffed, that wouldn't leave anything for 
volunteers to do which would be bad for new recruits. Even so, it's difficult 
to feel good when contributors are pinging you asking why their patch isn't 
reviewed in a couple days or weeks. I've tried to emphasis that *anyone* 
(except the patch author) can review patches and mark the ticket as "ready for 
checkin", but there are still many more code contributors than patch reviewers 
these days.

If I were starting as a new fellow, I would set up a separate email account for 
all my Django activity so that I don't see those notices in my personal mail on 
evenings and weekends.

I grew tiresome of teaching new contributors. Most regular contributors submit 
high quality patches that are generally easy to review but most new 
contributors don't take time to read our style guide and follow the patch 
review checklist. Only a very small number of contributors become regular 
contributors and sometimes I've thought that the effort to teach new 
contributors who don't stick around is very inefficient. I guess this is fine 
as long as fellows recognize that their job is partly educational.

I could write more but I want to put something out before Friday. If you're 
thinking of applying and have a question or doubt, please ask.

* https://www.djangoproject.com/weblog/2018/dec/21/django-fellow-applicants/
--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com<mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/184aa8ec-69f4-4b79-9ea9-2a555c2fc75e%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/184aa8ec-69f4-4b79-9ea9-2a555c2fc75e%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce8d083516834789b9af517449a4d268%40iss2.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: GSoC 2019 Update

[Matthew Pava]

This is more for the ORM side of things. Something I would like to see is the 
Subquery object morphed into the equivalent of common table expressions and the 
possibility of having recursive common table expressions.  See 
https://code.djangoproject.com/ticket/28919.
The patches that I’ve seen simply add yet another object to the library. I once 
looked at the ORM internals to try to understand it, and I even found a video 
from James Bennett that discussed contributions to Django. Unfortunately, he 
quickly glossed over the ORM internals that I was really interested in learning 
more about, but it’s just because it’s so complex. Maybe simplifying that code 
is a project in and of itself, but I imagine that you would need expert 
understanding of Django.

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Tim Graham
Sent: Thursday, March 7, 2019 9:01 AM
To: Django developers (Contributions to Django itself)
Subject: Re: GSoC 2019 Update

I agree that a cross-database JSONField probably wouldn't take 3 months to 
implement -- but it would be up to the student to write a proposal and timeline 
that demonstrates there's 12 weeks of work. Students are supposed to be working 
full time.

GSoC requires writing code so an acceptable project can't be exclusively 
documentation.

The problem is that we need students to contribute to Django beforehand so we 
have some assurance they do good work. Also, students need significant 
familiarity with Django to write their proposal. It's unlikely a student can do 
all this in the next 3 weeks (alongside a normal course load).

On Thursday, March 7, 2019 at 6:22:02 AM UTC-5, Carlton Gibson wrote:
Hi all.

We were accepted as an Org to GSoC, so we can accept applications from the end 
of the month.

I've updated the Wiki page...

https://code.djangoproject.com/wiki/SummerOfCode2019

... but if you have project ideas it would be good if you could add them!


I keep hearing, "Django's Mature", "There are no suitable projects" but I look 
at the >1300 accepted tickets and, well... I just don't believe that really. 🙂

Taking Aymeric's advice, I broke down the accepted tickets by component:



[Django-Accepted-tickets-by-component.png]



The top 4 there are:



* ORM

* Admin

* Documentation

* Migrations.



For the ORM, I think the cross-DB JSONField would be a great project. Florian 
worried it was too small in scope, but if it existed by the end of the summer, 
I would call that a success.



ORM experts: what else though? (Anything?)



For the Admin, there are a whole load of "filters" tickets. (Including the 
search issue from the thread here the other day). I've added working on that as 
an idea. But anything else?



  *   What we could really do with is someone becoming an expert in a component 
and taking on a bunch of issues — Would that count as an acceptable project?
  *   Could we do that for Documentation? (Would require strong written 
English. Focus on Clarity. But...)

Other ideas around the docker-box project and CI? Could we take input there?
Translations tooling and flow?
And so on...?

Last chance to speak up. 🙂

I'm hopeful we can get a decent application (or a few…) Let's see.

Thanks.

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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b9c2356-1878-4e45-9026-2a9ac6b9f193%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0667d821cab943eda763d5a1bb041668%40iss2.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: Proposal to format Django using black

[Matthew Pava]

Just a thought: If Django were to adopt black (and I'm not saying it should), 
shouldn't it wait until it is out of the beta classification?

-Original Message-
From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Markus Holtermann
Sent: Thursday, May 2, 2019 11:06 AM
To: Django developers
Subject: Re: Proposal to format Django using black

The primary author of Black, Łukasz Langa, just announced that Black was moved 
under the PSF umbrella: https://twitter.com/llanga/status/1123980466292445190

I updated the link in the DEP-8 accordingly to https://github.com/python/black/

/Markus

On Wed, May 1, 2019, at 2:32 AM, Andrew Godwin wrote:
> Hi all,
> 
> As per the DEP process, I have merged DEP 8, Formatting Code With 
> Black, into the DEP repo as a draft. This doesn't mean it's decided yet 
> - any DEP that meets quality requirements gets merged as a draft - but 
> it means that we're one step closer to doing so.
> 
> What follows is further discussion until it is either revised, 
> withdrawn, or the author thinks they have enough feedback to put it to 
> the technical board.
> 
> I will draw attention to the following part of DEP 1:
> 
> "However, wherever possible, long open-ended discussions on public 
> mailing lists should be avoided. Strategies to keep the discussions 
> efficient include: setting up a separate mailing list for the topic, 
> having the DEP author accept private comments in the early design 
> phases, setting up a wiki page, etc. DEP authors should use their 
> discretion here"
> 
> Given this thread is now over 100 replies long, we might want to 
> consider a better avenue for constructive feedback.
> 
> Andrew
> 
> On Tue, Apr 30, 2019 at 12:31 PM Christian González 
>  wrote:
> > 
> >  Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
> >  (Contributions to Django itself):
> >  > The Chrome team fixed this issue with
> >  > git-hyper-blame: 
> > https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
> >  >
> >  >
> >  > That could be a solution that would work for Django. IDE support for
> >  > git-hyper-blame is lacking (at the moment) but might improve in the
> >  > future.
> > 
> >  I made a feature request for git itself, and they told me this is
> >  already in the works *within* git dev:
> > 
> > https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/
> > 
> >  So on the long run, no need for git-hyper-blame.
> > 
> >  Christian
> > 
> >  -- 
> >  Dr. Christian González
> > https://nerdocs.at
> > 
> >  -- 
> >  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 post to this group, send email to django-developers@googlegroups.com.
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/74e4842c-24fa-6055-2b1e-d70b42153b69%40nerdocs.at.
> >  For more options, visit https://groups.google.com/d/optout.
> 
>  -- 
>  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 post to this group, send email to 
> django-developers@googlegroups.com.
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAFwN1uq0AEP4wL0%3D1xQOF%2BWBVQfGgU5Zfz0V5BurVCbyMeOA3Q%40mail.gmail.com
>  
> .
>  For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97b94a37-430f-40c6-9160-562f03ace56c%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 

RE: Prefixing Q Objects

[Matthew Pava]

I had a use for such a feature, though I used an implementation more specific 
to my application.
Basically, I have a model and then I have several other models that are 
directly related to that model. So in the base model I would have a field to 
determine if the instance was marked as deleted. I don’t have this field in the 
sub-models, so I would pass in the related name of the base model to create a 
queryset of all instances of the submodels that should be marked as deleted. 
Actually, that’s not exactly what I was doing, but the concept is there. Saying 
that, I am only doing that on one field on one model in my project.

From: 'Robert Schindler' via Django developers (Contributions to Django itself) 
[mailto:django-developers@googlegroups.com]
Sent: Wednesday, July 10, 2019 2:13 PM
To: Django developers (Contributions to Django itself)
Subject: Prefixing Q Objects

Hi all,

I've been redirected to the mailing list from the ticked I opened [0]. Therein, 
I proposed to add a new method to the Q object API for prefixing Q objects with 
a related field's name in order to be able to create reusable Q objects.

I think the use case I pointed out might have been misunderstood. Such an API 
would allow writing a manager like this one, let's say for a Subscription model:

class SubscriptionManager(Manager):
def active_q(self):
return Q(cancelled=False) & Q(end_date__lt=datetime.datetime.now())

# This one is just for convenience and compatibility with the evolved 
practice
def active(self):
return self.filter(self.active_q())

We could then perform the following lookups:

# All active subscriptions, nothing special here
Subscription.objects.active()
# Given that a user has a ManyToManyField subscriptions, get all users with 
active subscriptions, without repeating any business logic
User.objects.filter(Subscription.objects.active_q().prefix("subscriptions"))

The traditional approach would be to implement methods for filtering the 
queryset on both the managers for Subscription and User and thus duplicating 
logic, or use sub-queries like so:

User.objects.filter(subscriptions__in=Subscription.objects.active())

which is clearly not wanted because of performance.

What are your opinions?

Best regards
Robert

[0] https://code.djangoproject.com/ticket/30631


--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30020900-7a4a-442e-9cce-af3d75a27c15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0c0a9f8a6dae49388bae789b926b9477%40iss2.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: Redis cache support in core

[Matthew Pava]

I’d just like to point out that Redis support on Windows is limited at best. 
All other technologies that Django uses, as far as I can recall, do support 
Windows.

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Jacob Rief
Sent: Thursday, September 5, 2019 1:33 AM
To: django-developers@googlegroups.com
Subject: Re: Redis cache support in core

I'm also in favor on having it as part of the core, since memcache is also 
supported.

One of the nice features Redis provides, is the possibility to invalidate one 
or more cached object by using a wildcard key.
It namely is the method delete_pattern() added by django-redis-cache to the 
given Django caching backend. That
(or a similar method) then should be part of the other Django caching backends 
as well, such as the dummy cache or in-memory cache.

Jacob
--
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/CAJ_HXxo9jpr-%3DFmLXcYwwR6tdn-NVDfrEoo-qYnB-vQwKv9O%3DA%40mail.gmail.com.

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

RE: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

['Matthew Pava' via Django developers (Contributions to Django itself)]

Hi Bill,
We ended up using a package called Django-audit-log: 
https://pypi.org/project/django-audit-log/.
It’s outdated now, but we used the source code for their CreatingUserField, 
LastUserField, CreationDateTimeField, and ModificationDateTimeField. More 
modern packages may have enhanced features than these.

In your case, I may just add a save method to the abstract model and add 
timezone.now() to the corresponding fields. If there’s not a pk, then populate 
the created date field.

You are right, though. Perhaps the Django community can explain the issue 
between auto_now and auto_now_add fields.

From: 'William Palin' via Django developers (Contributions to Django itself) 

Sent: Sunday, March 17, 2024 9:59 AM
To: Django developers (Contributions to Django itself) 

Subject: Intermittent IntegrityError on Model Save with auto_now and 
auto_now_add Fields


Hello Django community,



We are reaching out after encountering a persistent and elusive issue that 
manifests as an IntegrityError during the save operation of a Django model. 
This problem has been sporadically occurring since last year and has 
successfully stumped four seasoned Django developers on our team. The error 
seems to involve the non-update of auto_now fields upon model save, leading us 
to suspect a deeper issue within Django, though we are cautious about drawing 
premature conclusions. Given the complex and intermittent nature of this bug, 
we are seeking insights, advice, or any form of guidance from the community.


Issue Overview:



Our model inherits date_created and date_modified fields from an abstract base 
class designed to standardize these timestamps across our models. Here is how 
the abstract base class is defined:




class AbstractDateTimeModel(models.Model):

"""An abstract base class for most models"""



date_created = models.DateTimeField(

help_text="The moment when the item was created.",

auto_now_add=True,

db_index=True,

)

date_modified = models.DateTimeField(

help_text="The last moment when the item was modified. A value in year"

  " 1750 indicates the value is unknown",

auto_now=True,

db_index=True,

)



class Meta:

abstract = True


The Problem:


Intermittently, the .save() method triggers an IntegrityError, apparently 
because the auto_now field (date_modified) does not get created. A specific 
instance of this error showed that while date_created is correctly populated, 
date_modified remains null, which directly leads to the IntegrityError upon 
attempting to insert the record:


[datetime.datetime(2023, 10, 2, 14, 33, 49, 99833, 
tzinfo=datetime.timezone.utc), None, ...]

'INSERT INTO "search_docket" ("date_created", "date_modified",... ]


What We've Tried:



  *   Investigated the possibility of an issue with update_fields being 
non-null and excluding date_modified during .save(), but confirmed through 
Sentry logs that update_fields was indeed None in all instances of the error.
  *   Attempted to reproduce the issue in a controlled environment without 
success, leaving us without a clear direction for a solution.



Request for Help:



We're wondering if this could point to an undocumented edge case in Django's 
auto_now and auto_now_add implementation or a specific database behavior under 
certain conditions. Any advice on further debugging steps, experiences with 
similar issues, or knowledge of potential Django nuances that we might not be 
considering would be incredibly valuable.



We appreciate your time and any feedback or suggestions you can offer.



Thanks



Bill



django v5.0.2

python 3.12.2

db is postgres

--
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/a788c065-3a96-472c-9b41-7c2aebca6967n%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/DS7PR15MB5910838A1CE2563A49DADC61822D2%40DS7PR15MB5910.namprd15.prod.outlook.com.