Re: Inconsistent pagination when sorting by non-unique columns (ticket 34251)

[Adrian Torres]

I've been bitten by this once before as well but I think it's the kind of 
mistake you make once and never again, and if you happen to encounter it 
again you immediately know what it is (duplicated/missing items across 
pages? must be a non-unique ordering).

I don't think implicitly adding an extra field to order by is a good 
solution because the user might be totally unaware that such a thing is 
happening, maybe it could be a setting? e.g. (ENFORCE_TOTAL_ORDERING) and 
it should **only** be applied in the context of paginated querysets, but I 
would be more in favor of adding a warning to the pagination documentation.

I don't think warnings would work, because as soon as you get a 
"false-positive" users would simply filter/ignore the entire warning which 
would hide actual positives, but I guess it's better than nothing.

To sum up:
-1 on implicit pk ordering by default
+0 on implicit pk ordering via a setting
+0 on warnings
+1 on documentation update

On Wednesday, January 11, 2023 at 4:35:24 PM UTC+1 tatari...@gmail.com 
wrote:

> Thanks for the input, Barry!
> To be clear - Django already enforces total ordering in the admin panel by 
> adding "pk" (in this method 
> ),
>  
> which makes me believe that's a viable approach.
> Sure, there can be domain-specific unique/unique_together fields that 
> ensure consistent ordering as well, that's why it first checks to see if 
> those were used.
> What is your solution? Does your frontend/UI provide the "stocking 
> number"/"stocking number and store" as the final parameter(s) or do you 
> somehow inject them in the VIew? 
> P.S. I believe `warnings.filterwarnings` can be used to suppress specific 
> warnings. 
> On Wednesday, 11 January 2023 at 16:59:41 UTC+2 bajo...@epicor.com wrote:
>
>>
>> I'd be very much -1 if the framework modified my sorting parameters (by 
>> adding 'pk' at the end of the ordering).  As mentioned, it can certainly 
>> break queries that can be handled by a covering index...  but mostly 
>> because 'pk' isn't the field we would prefer to use in this case anyway. 
>>  For example, when sorting a list of products, the final parameter ought to 
>> be the product's stocking number; when looking at items by store, the final 
>> parameter needs to be both stocking number and store.  There wouldn't seem 
>> to be -any- meaningful "always right" answer.
>>
>> We have something like 20,000 tests running today (and will probably hit 
>> 40,000 over time), many of which do pagination and sorting.   I'd really, 
>> really hate to have to go fix all of those tests -- it would be thousands 
>> of them.  If there was a way to disable this proposed warning, I could live 
>> with that for a while.
>>
>> baj
>> -
>> Barry Johnson
>>
>> On Wednesday, January 11, 2023 at 6:55:25 AM UTC-6 tatari...@gmail.com 
>> wrote:
>>
>>> As described in https://code.djangoproject.com/ticket/34251, some 
>>> database backends (incl. PostgreSQL) will produce non-deterministic 
>>> ordering when sorting by columns with non-unique values.
>>> This leads to inconsistent pagination, which I argue falls under the 
>>> same category as paginating by unordered QuerySet. 
>>>
>>> I suggest we add a warning similar to the UnorderedObjectListWarning 
>>> when total deterministic ordering is not specified (PK or 
>>> unique/unique_together not null fields).
>>>
>>> The consequence of this change is that *a lot* of projects will receive 
>>> a warning. This issue is easy to overlook since non-unique columns like 
>>> "name" can have mostly unique values and you need to have duplicates at the 
>>> page borders to get into trouble. While seemingly hard to reproduce, I 
>>> believe it impacts a lot of production systems out there.
>>>
>>> Correctly handling it requires some thought, especially when exposing 
>>> sorting options to the end user. Whether 3rd-party tools like 
>>> django-sortable-listview 
>>>  or DRF 
>>>  (OrderingFilter) 
>>> should automatically enforce the correct ordering by adding "pk"? This 
>>> brings problems with indexing like in this ticket 
>>> . Another option with 
>>> these tools is adding *pk* or another unique field to the query string 
>>> when specifying desired sorting, which looks just wrong to me, pushing 
>>> responsibility to the front end.
>>>
>>> What do you folks think? I've been bitten by this issue several times, 
>>> in a production environment after smoothly running for a while. The first 
>>> time was a complete surprise to me, and I believe it's may surprise quite a 
>>> lot of developers as well, so adding a warning will at least bring the 
>>> attention. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django 

Re: ticket 5929

[Adrian Torres]

I feel like this is a very niche use case and probably doesn't warrant 
implementing field-to-column one-to-many relationships in Django, I don't 
see why this specific case can't be implemented as:

1. A model that implements the data type
2. A custom field + custom datatype on the database backend
3. ArrayField [1] if using postgres

[1] 
https://docs.djangoproject.com/en/4.1/ref/contrib/postgres/fields/#arrayfield
On Monday, January 9, 2023 at 12:16:56 AM UTC+1 cur...@tinbrain.net wrote:

> On Sun, 8 Jan 2023, at 23:29, Barhamou Hama wrote:
>
> Hi all, I came across this ticket here 
>  opened 15 years ago that 
> doesn't seem to have been resolved. I decided to work on it. But in 15 
> years a lot can happen. Is it still relevant? Has there been any progress 
> on this issue?
>  
>
>
> IIRC there's no current support for this, the closest being 
> GenericForeignKeys, which still require their sub-fields defined separately.
>
> There has been posts about supporting joint using multi-field keys (
> https://devblog.kogan.com/blog/custom-relationships-in-django) however, 
> that's a rather specific case.
>
> I think it would be a good thing for progress on this issue to happen.
>
> You might also want to check the ticket history for any work on 
> multi-value keys.
>
> --
> Curtis
>
>
>

-- 
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/6b636002-3eb9-44f3-9510-89d7319f8231n%40googlegroups.com.

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

[Adrian Torres]

I'd personally like to see better support for safe / N-1 compatible 
migrations within Django itself, currently if you do CD / blue-green tower 
/ etc. deployments you need to be very careful about the migration 
operations that you introduce version-to-version, although I'm not sure 
what that would look like.

+1 to OIDC, CORS and DB defaults

If nothing else, this thread has at least made me aware of some interesting 
tickets :-)

Adrian

On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:

> I am not sure the db level defaults PR is suitable for a GSoC project at 
> this point - it’s pretty well developed. I think it could do with some 
> review and testing form those who are interested.
>
> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
> developers (Contributions to Django itself)  
> wrote:
>
>> +1 from me on DB defaults (constraints too). I've worked on many systems 
>> where Django isn't the only place putting records into DBs and having DB 
>> level defaults and constraints fixes a lot of common issues with that. 
>> Currently I create an empty migrations to then add them in manually when 
>> required
>>
>>
>> +1 from me on moving models between apps, though I know it can be a pain. 
>> Contacting and freelancing means you come across a lot of projects where 
>> models are seeming in the wrong app or where you want to consolidate apps 
>> and being able to move them cleaning would be a wonderful addition
>> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>>
>>> I'd like to see database-level defaults supported in models and 
>>> migrations:
>>>
>>> https://code.djangoproject.com/ticket/470
>>>
>>> There's currently a PR open, which replaces an earlier 2020 PR
>>>
>>> https://github.com/django/django/pull/16092
>>>
>>> It would be a large benefit to those of us practicing continuous 
>>> deployment. It is also tricky enough that it would benefit from a full-time 
>>> effort to implement and refactor.
>>>
>>> - John
>>>
>>> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
>>> 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 real boon. Recent 
 successes include: 

 * The django-stubs mypy plugin. 
 * The cross-db JSON field. 
 * The Redis cache backend. 
 * Per model-class (field instance) custom lookups
 * Setup of the django-asv benchmarking project. 
 * ... 

 Application deadline for Orgs is February 7. I'll begin working on it 
 after the New Year. 

 Main bit is an ideas list for projects. The GSoC guide has a Writing a 
 Good Ideas List
 section. 

 > Projects should take ~175 hours or ~350 hours for GSoC contributors 
 to complete. 

 i.e. "short" or "long" projects. 
 https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

 I'm writing here *to solicit input on project ideas*. 

 I put "Technical Board?" in the subject because we're short a list of 
 project
 ideas for the technical direction of Django going forward, and maybe 
 thinking
 in terms of GSoC could be a way of bootstrapping that. The "?" is 
 because that's not 
 meant to exclude other input.

 Here's last year's list for reference: 
 https://code.djangoproject.com/wiki/SummerOfCode2022

 - Some of those were done: benchmarking (but that could be built on) 
 and per-instance 
   field lookups.

 - Rate-limiting is a no-go I think: we couldn't come to any decent 
 agreement on scope, 
   so it's better to live as a third-party package. 

 - I've tried to include folks from the wider ecosystem in previous 
 years. Two years ago 
   we had both Wagtail and django-stubs projects. Wagtail then (last 
 year)
   applied in their own right, to great success. I'd like to offer that 
 help
   again to e.g. Jazzband or other established projects, assuming 
 maintainers
   feel they have the capacity to mentor. (It's a minor increment to my 
 effort
   for a good return I think.)


 No urgency but, can I ask you to put your grey cells into action? 


 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-develop...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com
  
 

Re: Making max_length argument optional

[Adrian Torres]

I finally had some time to do some work on this and have submitted a patch 
at https://github.com/django/django/pull/16302 in case anyone is interested.

On Wednesday, October 5, 2022 at 2:24:35 PM UTC+2 carlton...@gmail.com 
wrote:

> Hi Adrian. 
>  
> Nothing has been done, no. 
>
> There seem to be a few competing options: 
>
> 1. Allow max_length=None on Postgres (using a 
> supports_unlimited_charfields, name!?, DB backend feature flag maybe 樂)
> 2. Add an unlimited flag to CharField. 
> 3. Have a subclass in contrib.postgres, similar to JKM's version Tom 
> linked before 
> <https://github.com/jacobian/django-postgres-unlimited-varchar/blob/master/django_postgres_unlimited_varchar.py>
>
> My guess would be 1 or 3. (I'd rather 3 than 2.) So proof-of-concepts 
> implementing those would be the way forward I think. 
>
> Kind Regards,
>
> Carlton
>
>
> On Wed, 5 Oct 2022 at 12:47, Adrian Torres  wrote:
>
>> Sorry for reviving the thread but just ran into this issue again and 
>> wanted to ask, has there anything been done to address this?
>>
>> For me having max_length=None mean "unlimited varchar" for Postgres and 
>> being an error for any other database (or those that don't support 
>> unlimited varchar) is the best solution, but I'm also ok with Carlton's 
>> idea of having a subclass in contrib.postgres is an acceptable compromise.
>>
>> Cheers,
>> Adrian
>>
>> On Monday, August 17, 2020 at 11:26:39 AM UTC+2 t...@carrick.eu wrote:
>>
>>> It would work for my use-cases. It was mentioned that it's maybe not the 
>>> best as a lot of fields subclass CharField, but I don't see a compelling 
>>> argument for an unlimited email or slug field. The one problem I see is 
>>> CICharField, you might want to make that unlimited - but the CI fields are 
>>> more or less redundant on pg >= 12 once we have column collations in. So I 
>>> think it's okay for now. Only problem I can see is if we add more CharField 
>>> subclasses in the future...
>>>
>>> On Mon, 17 Aug 2020 at 11:02, Carlton Gibson  
>>> wrote:
>>>
>>>> Would the subclass in contrib.postgres suggestion be acceptable? 
>>>>
>>>> On Mon, 17 Aug 2020 at 10:31, Tom Carrick  wrote:
>>>>
>>>>> I'm not a fan of any solution either, really, even the one I suggested.
>>>>>
>>>>> I think adding a new kwarg, "unlimited" seems okay to me, though it 
>>>>> feels a little redundant.
>>>>>
>>>>> I don't like the idea of using TextField, I find them semantically 
>>>>> different. An unlimited varchar says to me "one possibly very long 
>>>>> thing", 
>>>>> whereas TextField feels more like it's free text, or a document, 
>>>>> especially 
>>>>> as the form fields are different. Subclassing CharField is an option, but 
>>>>> the methods I've seen to do this makes it annoying. I need this so often 
>>>>> that I do it all the time, but the code is so short that I don't want to 
>>>>> bring in a new package to do it. Also, the popular ways to do this are 
>>>>> not 
>>>>> great. One way is to just set the max_length extremely high, which is not 
>>>>> what I want ending up in the database, the other is something like 
>>>>> this <https://github.com/jacobian/django-postgres-unlimited-varchar>, 
>>>>> which works well, but will stop working well once column collations are 
>>>>> in 
>>>>> as that PR adds more stuff to CharField.__init__().
>>>>>
>>>>> I think it's time we had something in Django, whatever that ends up 
>>>>> being.
>>>>>
>>>>> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson  
>>>>> wrote:
>>>>>
>>>>>> Reading the history, I see an awful lot of -1s to the idea of a 
>>>>>> default. 
>>>>>>
>>>>>> I see “use a TextField” and “use a subclass” a few times, which were 
>>>>>> my immediate thoughts just on the recent emails. 
>>>>>>
>>>>>> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>>>>>>
>>>>>>> I’m not a fan of implicit max_lengths. Is having to add a keyword 
>>>>>>> argument to a model field really that much of a burden? And we also 
>>>>>>> would 
>>>>>>> likely never be able to chan

Re: Making max_length argument optional

[Adrian Torres]

Sorry for reviving the thread but just ran into this issue again and wanted 
to ask, has there anything been done to address this?

For me having max_length=None mean "unlimited varchar" for Postgres and 
being an error for any other database (or those that don't support 
unlimited varchar) is the best solution, but I'm also ok with Carlton's 
idea of having a subclass in contrib.postgres is an acceptable compromise.

Cheers,
Adrian

On Monday, August 17, 2020 at 11:26:39 AM UTC+2 t...@carrick.eu wrote:

> It would work for my use-cases. It was mentioned that it's maybe not the 
> best as a lot of fields subclass CharField, but I don't see a compelling 
> argument for an unlimited email or slug field. The one problem I see is 
> CICharField, you might want to make that unlimited - but the CI fields are 
> more or less redundant on pg >= 12 once we have column collations in. So I 
> think it's okay for now. Only problem I can see is if we add more CharField 
> subclasses in the future...
>
> On Mon, 17 Aug 2020 at 11:02, Carlton Gibson  wrote:
>
>> Would the subclass in contrib.postgres suggestion be acceptable? 
>>
>> On Mon, 17 Aug 2020 at 10:31, Tom Carrick  wrote:
>>
>>> I'm not a fan of any solution either, really, even the one I suggested.
>>>
>>> I think adding a new kwarg, "unlimited" seems okay to me, though it 
>>> feels a little redundant.
>>>
>>> I don't like the idea of using TextField, I find them semantically 
>>> different. An unlimited varchar says to me "one possibly very long thing", 
>>> whereas TextField feels more like it's free text, or a document, especially 
>>> as the form fields are different. Subclassing CharField is an option, but 
>>> the methods I've seen to do this makes it annoying. I need this so often 
>>> that I do it all the time, but the code is so short that I don't want to 
>>> bring in a new package to do it. Also, the popular ways to do this are not 
>>> great. One way is to just set the max_length extremely high, which is not 
>>> what I want ending up in the database, the other is something like this 
>>> , which 
>>> works well, but will stop working well once column collations are in as 
>>> that PR adds more stuff to CharField.__init__().
>>>
>>> I think it's time we had something in Django, whatever that ends up 
>>> being.
>>>
>>> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson  
>>> wrote:
>>>
 Reading the history, I see an awful lot of -1s to the idea of a 
 default. 

 I see “use a TextField” and “use a subclass” a few times, which were my 
 immediate thoughts just on the recent emails. 

 On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:

> I’m not a fan of implicit max_lengths. Is having to add a keyword 
> argument to a model field really that much of a burden? And we also would 
> likely never be able to change the default without headaches.
>
> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>
> I'd like to revive this discussion and try to come to a consensus as 
> it's something I find myself wishing for (for Postgres in particular).
>
> My suggestion, after reading through everything:
>
> Give CharField a default max_length that is consistent across all 
> vendors. It doesn't really matter what the number is other than that it 
> should be large enough to be useful but small enough to work everywhere. 
> I 
> think 100 or 255 are both fine options.
>
> If you set max_length=None explicitly, on Postgres this will use an 
> unlimited varchar, on everything else will raise an exception on migrate.
>
> Any thoughts?
>
> Cheers,
> Tom
>
> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>
>> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote:
>>
>>
>> > I’m not too keen on a contrib.pg field. CharField is the base 
>> class of many
>>
>>
>> > fields, a __init__ kwarg approach such as max_length=None allows us 
>> to
>>
>>
>> > reach those as well.
>>
>>
>> > 
>>
>>
>>
>>
>>
>> That's a good point; Can we enable max_length=None in a mixin?
>>
>>
>>
>
>
>
>
> -- 
>
>
> You received this message because you are subscribed to the Google 
> Groups "Django developers (Contributions to Django itself)" group.
>
>
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com.
>
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%40googlegroups.com
>  
> 
> .
>
>
>
>
>

Re: Model-level validation

[Adrian Torres]

Hi,

Regardless of what you consider ModelForms to be, the fact that validation 
doesn't happen at the model level is very jarring if you've ever used any 
other MVC framework, it was and still is one of the major pet peeves of 
Django for me, to the point where we do something similar to what Uri does, 
and I'm sure many other people do.

bulk_update is not an excuse, as Aaron mentioned many other ORMs / 
frameworks come with features that forego certain safeties in favor of 
performance / convenience, heck you can write SQL directly if you so desire 
but you need to be ready to face the consequences.

I like the `UnvalidatedModel` vs `Model` idea proposed by Aaron.

Cheers,
Adrian

On Friday, September 30, 2022 at 3:39:20 AM UTC+2 aa...@aaronsmith.co wrote:

> I would also like everyone to know, my objective in starting this thread 
> is to get the go-ahead to open a PR for this. I would like to contribute 
> back.
>
> On Thursday, September 29, 2022 at 6:30:32 PM UTC-7 Aaron Smith wrote:
>
>> How about a new class, `ValidatedModel`, that subclasses `Model` and does 
>> nothing more than call `full_clean()` on `save()`?
>>
>> This would be completely backwards compatible, would clearly communicate 
>> what it does, and when documented right next to `Model` make it fairly 
>> obvious that Model is something other than validated, hopefully preventing 
>> many footguns.
>>
>> Or, and I think this would be better, if the current Model were renamed 
>> `UnvalidatedModel`, the new validated implementation above were `Model`. 
>> This upgrade path is a simple string replacement for those legacy codebases 
>> (Model->UnvalidatedModel), making it abundantly clear they are not 
>> validated, and new apps following the most naive path (Model) are as safe 
>> as possible. The new, validated, `Model.save()` could accept the kwarg 
>> `validate=False` as an opt-out, which as much as I hate to admit it is an 
>> important option for some codebases.
>>
>> On Thursday, September 29, 2022 at 5:19:07 PM UTC-7 cur...@tinbrain.net 
>> wrote:
>>
>>> On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote:
>>>
>>> Why doesn't Django validate Models on save()?
>>>
>>>
>>> The short answer is: backwards compatibility.
>>>
>>> Model level validation hasn't always been a thing, with Django initially 
>>> depending primarily on Form validation.
>>>
>>> Since it hadn't _always_ been there, it wasn't possible to introduce it, 
>>> enforce it, and not break most apps out there.
>>>
>>> There was so much code written that generally assumed it could call 
>>> `save()` and not have to catch validation errors.
>>>
>>> For what it's worth, I'm all in favor of making it run on `save()` ... 
>>> updating the documentation and preparing the community is going to be a 
>>> mammoth task, however. A safe course through this will take some very 
>>> careful planning.
>>>
>>> --
>>> C
>>>
>>

-- 
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/f51db24d-7c69-49f2-ad83-c8fd2418bfbdn%40googlegroups.com.

Re: Feature Request: New PostgreSQL ArrayField

[Adrian Torres]

Hi Liamine,

I think there's various solutions you could try before going the custom 
field route:

* You could try just using the 2D version and use some sentinel value for 
the date (NULL?) to treat the case where you just want an array of N prices.
* You could try using django-polymorphic [1] which would allow you to 
define one "StandardPricingProduct" model and one "CalendarPricingProduct" 
model, and be able to query them together (e.g. get all products regardless 
of "type").
* You could try Jacob's suggestion.
* You could try creating a pricing model and have a FK between Pricing and 
Product -- I know you want to avoid this, but to me it sounds simpler and 
more maintainable than going the custom field route.

Cheers,
Adrian

[1] https://django-polymorphic.readthedocs.io/en/stable/

On Wednesday, August 10, 2022 at 6:44:55 PM UTC+2 jacob...@gmail.com wrote:

> Hello Liamine,
> Django offers a JSONField 
>  
> which can be used to store an array.
> You can use it to store a list of prices. What's the benefit of using an 
> array instead of JSON?
> – 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/bbbfb68d-1167-45aa-bf8d-4f8b0346c411n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Adrian Torres Justo]

A common idiom is also

```
try:
foo = Foo.objects.get(x="foo")
except Foo.DoesNotExist:
foo = None
```

which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only 
argument on `get` that returns `None` if not found

```
foo = Foo.objects.get(x="foo", strict=False)
# or
foo = Foo.objects.get(x="foo", raises=False)
```

As it stands your current proposal isn't much different from filter() then 
first(), IMO, the method names change but the amount of chaining is the 
same.
On Monday, June 20, 2022 at 9:34:08 PM UTC+2 stev...@gmail.com wrote:

> It is a common idiom to use `.filter(<...>).first()` as a 
> replacement for `.get(<...>)` when `None` is wanted instead of an exception 
> when no match is found. That works, but wouldn't the intention be more 
> clear if that could be written as something like
>
> .checked(False).get(<...>)
>

-- 
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/eb6a2bc2-b72f-49ff-9e90-12913ad876c9n%40googlegroups.com.

Re: Improvements to the startproject template

[Adrian Torres Justo]

I personally dislike Adam's suggestion and feel like it makes it worse than 
the current default, but to each their own.

I do prefer the proposed solution of the config directory, I am working on 
two django projects in parallel and one follows the proposed config scheme 
and the other doesn't (uses the default) and I find the proposed config 
scheme more natural to use and navigate, so that's a +1 from me too

On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com wrote:

> For what it's worth, this is the (general) layout I've used for the past 
> 8+ years of my professional Django development.
>
> Arthur
>
> On Wed, 20 Apr 2022 at 15:22, Olivier Dalang  wrote:
>
>> +1 for Adam's suggestion, I use it as well and like it very much.
>>
>> > root folder
>> - manage.py
>> - ...
>> > myproject
>> - __init__.py
>> - settings.py
>> - urls.py
>> - ...
>> > myapp
>> - __init__.py
>> - models.py
>> - ...
>>
>> Pros:
>> - everything is well namespaced under myproject (`myproject.settings`, 
>> quite straightforward)
>> - makes it clear that `settings.py`, `urls.py`, etc. concern the project 
>> as a whole, and not just an app.
>> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear 
>> that myapp is part of this project)
>> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, so 
>> the actual source stays clean from such files.
>> - having a parent package allows (does not require) relative imports 
>> across modules of the same project, which more clearly conveys that such 
>> apps are tightly coupled
>> - with manage.py still in the root folder, you don't need to cd into any 
>> folder to start working
>>
>> I use it all the time.
>>
>> Cheers,
>>
>> Olivier
>>
>>
>>
>>
>> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>>
>>> I prefer Adam's suggestion in the forum post as it lets you namespace 
>>> everything under your project name nicely and avoids package name 
>>> collisions, although it doesn't solve the problem of having two directories 
>>> with the same name by default.
>>>
>>> That said, either would be an improvement on what we have so I'm in 
>>> favour of either approach over doing nothing.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 20 Apr 2022 at 16:49, John M  wrote:
>>>
 I do exactly this for every new Django project, so it's +1 from me as 
 well.

 John
 On 20/04/2022 12:01, da...@springbourne-tech.com wrote:

 +1 for me - this would be really useful.

 On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org 
 wrote:

> Hi Tim,
>
> This feels like a good idea to me.
>
> Regards,
> Ian
>
> On Mon, 18 Apr 2022 at 18:17, Tim Allen  
> wrote:
>
>> Greetings, friends! 
>>
>> I've issued a PR that makes two changes to the 
>> `startproject` template:
>>
>>- instead of putting configuration files such 
>>as `settings.py`, `wsgi.py`, and the 
>>root `urls.py` in `my_project/my_project`, they are created 
>>in `my_project/config` 
>>- start the project with a custom User model app, `users` 
>>
>> Over the years, I've taught or tutored over 100 Djangonauts starting 
>> their first project. Having to distinguish between two directories with 
>> the 
>> same name is a constant pain point in the teaching process - "cd into 
>> my_project ... no, the other one!"
>>
>>- The `config` option seemed to be the consensus from this thread 
>>in the forum: Django New Project Structure/Name - Using Django - 
>>Django Forum (djangoproject.com) 
>>
>> 
>>  
>>- Ticket: https://github.com/django/django/pull/15609 
>>
>> It is sometimes better to show rather than tell, so following our own 
>> documentation and including a custom User model with the initial project 
>> template reinforces the best practice that we explicitly point out in 
>> the 
>> documentation.
>>
>>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) 
>>– Django (djangoproject.com) 
>> 
>>- Avoids ever having this come up again: 
>>
>> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>>  
>>
>> Here's a link to the PR: https://github.com/django/django/pull/15609
>>
>> My apologies for not starting with a discussion first. I'm an 
>> infrequent contributor to the Django codebase!
>>
>> Regards,
>>
>> Tim
>>
> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group 

Re: RFC #33561 -- Synchronize user attributes on every authentication with RemoteUserBackend

[Adrian Torres Justo]

Alright, I'm still not 100% convinced it wouldn't be best having them as 
separate methods, but for the sake of moving things along I'll implement it.

One thing that's not quite clear: you mentioned adding a backwards 
compatibility warning, is this the same as a RemovedInDjangoXXWarning? 
Should I follow the documentation at [1] for this implementation?

[1] 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature

Cheers,
Adrian

On Saturday, March 5, 2022 at 7:30:18 PM UTC+1 f.apo...@gmail.com wrote:

> Hi Adrian,
>
> On Saturday, March 5, 2022 at 5:13:14 PM UTC+1 ator...@redhat.com wrote:
>
>> - Existing RemoteUserBackend implementations won't need to change 
>> signatures whenever backwards compatibility is removed
>> - RemoteUserBackend implementations won't need to do anything in order to 
>> support Django versions in which the feature doesn't exist (e.g. 3.9) and 
>> versions in which the feature exists and is not backwards-compatible (e.g. 
>> 5.1)
>>
>
> While this is true, the "migration" path for implementors is simply to 
> change the function to something like:
>
> ```
> def configure_user(self, request, user, created=False):
> if not created: return
>… do whatever you already did 
> ```
>
> and it will stay compatible with current behavior and the new behavior.
>  
>
>> - The code footprint within Django, not counting documentation and tests, 
>> is like 3 LOC
>>
>
> I do understand that, but I don't think it is as simple as that. With the 
> separated methods (unless we pass created to synchronize_user as well) 
> you'd do synchronization always even when the user was just created even 
> though configure_user could take care of that in one go.
>
> - Anyone who wants to extend a RemoteUserBackend implementation can easily 
>> and cleanly extend/replace the synchronization and initial setup 
>> independently of each other, if everything is done in the same method this 
>> can get messy
>>
>
> I do not really think this will be the case since those methods are empty 
> by default… Those backends are so simple that at some point one can simply 
> write their own if subclassing might become to much of a hazzle.
>  
>
>> def configure_user(self, request, user, created):
>> if created:
>> user = self.initial_configuration(request, user)
>> user = self.synchronize(request, user)
>> return user
>>
>> Which is the same as having two separate methods for initial 
>> configuration and synchronization, but with extra steps.
>>
>
> I do not think this will be common though. I rather think that usually one 
> would do the same thing on creation and on sync. 
>  
>
>> Have a good weekend
>>
>
> Thanks, you as well!
>
> Florian 
>

-- 
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/cbb24085-a610-44ec-a5df-f58e6ab06f0cn%40googlegroups.com.

Re: RFC #33561 -- Synchronize user attributes on every authentication with RemoteUserBackend

[Adrian Torres Justo]

Hey Florian,

First of all, thank you for the feedback and I'm glad you agree that the
feature would be nice to have :)

I'm willing to implement whichever version people agree on since I do think
the feature will be useful, but I do think that having separate methods is
clearer, simpler, as well as easier to maintain and extend:

- Existing RemoteUserBackend implementations won't need to change
signatures whenever backwards compatibility is removed
- RemoteUserBackend implementations won't need to do anything in order to
support Django versions in which the feature doesn't exist (e.g. 3.9) and
versions in which the feature exists and is not backwards-compatible (e.g.
5.1)
- The code footprint within Django, not counting documentation and tests,
is like 3 LOC
- Anyone who wants to extend a RemoteUserBackend implementation can easily
and cleanly extend/replace the synchronization and initial setup
independently of each other, if everything is done in the same method this
can get messy

That last point might lead implementors to define their configure_user like
so:

def configure_user(self, request, user, created):
if created:
user = self.initial_configuration(request, user)
user = self.synchronize(request, user)
return user

Which is the same as having two separate methods for initial configuration
and synchronization, but with extra steps.

Have a good weekend,
Adrian


On Sat, Mar 5, 2022 at 12:54 PM Florian Apolloner 
wrote:

> Hi Adrian,
>
> I agree this would be nice to have.
>
> On Friday, March 4, 2022 at 8:03:09 PM UTC+1 ator...@redhat.com wrote:
>
>> Another idea would be to use configure_user() for both initial
>> configuration and synchronization by passing an extra parameter "created"
>> to it, and calling it just before the authenticate method's return line,
>> but I figured this change would be more disruptive for existing
>> implementations.
>>
>
> I do prefer that approach. It is not more disruptive (or at least only
> marginally) and only means more work (backwards compat warnings) when
> implementing this. We can easily inspect the existing signature and only
> pass the boolean when supported and in the backwards compatibility period
> simply do not support created=False when the user didn't change their
> configure_user signature. I'd hate seeing two methods that basically do the
> same.
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/dn_E9IzayZA/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/9db3b605-a8fc-40ab-a318-0ff1e7a76eb3n%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/CAAC-pBMUwpHDmE%3D_CoWBpJtRhA89sWVKmgADr4i_LCNqkJAQUg%40mail.gmail.com.

RFC #33561 -- Synchronize user attributes on every authentication with RemoteUserBackend

[Adrian Torres Justo]

Hello all,

I'd like to get your feedback and comments regarding the ticket mentioned 
in the subject line: adding a mechanism/hook to the RemoteUserBackend that 
allows for synchronization of user attributes between the remote system and 
the django server on each authentication attempt.

Synchronizing data between the remote system and the django server is 
useful for obvious reasons, however the ticket was marked as WONTFIX 
arguing that the same can be achieved by overriding authenticate().

While the behavior is similar, it is not the same: My implementation (see 
linked patch in Trac) synchronizes data right before the return line of the 
authenticate() method, which checks whether the user can authenticate by 
calling user_can_authenticate() whose result can be influenced by the 
synchronization, which is why I did it right before it.

You could argue that then one can simply override user_can_authenticate() 
and call the synchronization method from there, and you would be right, 
however this is not obvious to RemoteUserBackend implementors and feels 
more like a hack than anything else, not to mention you wouldn't know this 
without reading the source code, which is what I had to do in order to 
implement this functionality in another project (and what led me to submit 
the patch in the first place).

Ultimately, the argument could be used for the clean_username hook too, why 
have such a hook if one can simply override authenticate() and perform the 
cleaning right before calling authenticate()?

Another idea would be to use configure_user() for both initial 
configuration and synchronization by passing an extra parameter "created" 
to it, and calling it just before the authenticate method's return line, 
but I figured this change would be more disruptive for existing 
implementations. 

Thank you in advance for your inputs,
Adrian

-- 
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/e0e832cd-9b73-4824-a537-5f34a78a9b85n%40googlegroups.com.