Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Jure Erznožnik]

I too am in favour of this change.

But I read Andrew's comment differently: it's maybe not the 60 
characters, but some sort of "aggregation" we could be looking for. So 
maybe instead of "0026_remove_book_title_add_book_description" we could 
have "0026_book_add_remove" - especially when multiple fields were involved.


Alternatively, makemigrations could also generate multiple migrations 
(by default?) in order to obtain the goal of meaningful names? Have a 
parameter to force combining?


LP,
Jure

On 23/04/2020 21:34, Adam Johnson wrote:

Thank you all for the feedback.

Re: Andrew:

(60 is a bit long though, maybe we can bump it down to something a
bit shorter?)


Sure, how about 42? 👽

Re: Jon:

Did you have a suggestion for this situation? Revert back to
auto-naming or request the user to name the migration?


The patch as-is accumulates suggested names from operations in order, 
until the length is >=60 characters. Later operations just aren't 
mentioned.


Re: Claude:

An alternative could be to ask the user in interactive mode (and
keep the current behaviour in non-interactive mode).


I'd be up for this if we "pre-fill" the input with the auto-generated 
name, to make it easy to continue when we can suggest a reasonable 
name. Forcing users to type a name from scratch could be annoying 
especially when iterating on a new feature and dropping/rebuilding the 
respective migration.


Re: Caio:

I work on a project where migration names are fixed to “auto”. We
use a similar technique to those mentioned in the blog post to do
that. The reason is that we want to force developers to get
conflicts (git) on migration names during the review process,
rather than having to handle migration merging manually during deploy


Yes, this is a secondary problem with migrations, trying to keep the 
history linear via git.


I've used an alternative solution where a second file is created in 
the migrations folder called "latest" or similar, that simply contains 
the name of the latest migration file. This forces a conflict.


Although that's an alternative proposal, I think adding something like 
that to Django could be a good idea. It's better than forcing all 
migrations to have meaningless names.


On Wed, 22 Apr 2020 at 16:47, Andrew Godwin > wrote:


I am a little mixed on this change - the behaviour during the
initial development was indeed to concatenate names like this,
albeit only for adding fields or models; I thought it looked
unwieldy, which is why I added the "auto" name.

That said, the number is the only part that actually matters, and
while the date is sometimes useful for people to resolve merge
conflicts, I don't think it's better than more informative
autogenerated names, so I'm happy to go with the change.

(60 is a bit long though, maybe we can bump it down to something a
bit shorter?)

Andrew

On Wed, Apr 22, 2020 at 7:06 AM Adam Johnson mailto:m...@adamj.eu>> wrote:

Hi djangonauts,

In a blog post earlier this year I outlined my technique to
prevent Django creating migration files with automatic date
names. I had a lot of response with other techniques and ended
up adding two more techniques to the post. It's at

https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
.

The problem with such migration names:

When you run Django’s |manage.py makemigrations|, it will
try to generate a name for the migration based upon its
contents. For example, if you are adding a single field,
it will call the migration |0002_mymodel_myfield.py|.
However when your migration contains more than one step,
it instead uses a simple ‘auto’ name with the current date
+ time, e.g. |0002_auto_20200113_1837.py|. You can provide
the |-n|/|--name| argument to |makemigrations|, but
developers often forget this.

Naming things is a known hard problem in programming.
Having migrations with these automatic names makes
managing them harder: You can’t tell which is which
without opening them, and you could still mix them up if
they have similar names due to being generated on the same
day.

Django *currently* sets the migration name to something other
than the automatic date name in two cases:

  * If the migration contains a single operation, it uses a
name based on that operation, e.g.
00023_remove_model_field, or 0024_add_model_field (but not
for all operation types)
  * If the migration consists *only* of model creation
operations, it combines their operation names names, which
come as just the lower-cased model names e.g.
0025_book_aut

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Adam Johnson]

I agree with Mariusz on the ticket/PR that my answer alone isn't enough
impetus to make this change. Hopefully someone more involved in i18n can
weigh in.

Although it changes the order of operations, I think this still works to
achieve the same behaviour. This snippet can be run at the end of a page to
wrap window.URLify.

(function () {
const originalURLify = window.URLify;

function URLify(s, num_chars, allowUnicode) {
let result = originalURLify(s, num_chars, allowUnicode);

const hadUnicodeChars = /[^\u-\u007f]/.test(s);
// Remove English words only if the string contains ASCII (English)
// characters.
if (!hasUnicodeChars) {
const removeList = [
"a", "an", "as", "at", "before", "but", "by", "for", "from",
"is", "in", "into", "like", "of", "off", "on", "onto",
"per",
"since", "than", "the", "this", "that", "to", "up", "via",
"with"
];
const r = new RegExp('\\b(' + removeList.join('|') + ')\\b',
'gi');
result = result.replace(r, '');
}
return result;
};

window.URLify = newURlify;
})();

On Thu, 23 Apr 2020 at 21:21, Andy Chosak  wrote:

> Thanks, Adam, for your reply. I've opened a ticket at
> https://code.djangoproject.com/ticket/31511, which includes a link to a
> PR that makes this change.
>
> Any advice on documenting how to wrap window.URLify?
>
> Thanks,
> Andy
>
> On Thursday, April 9, 2020 at 1:41:30 PM UTC-4, Adam Johnson wrote:
>>
>> I for one am quite surprised to learn the admin has this behaviour.
>>
>> I'm extra surprised it assumes it's in English if only ASCII letters are
>> used. This is quite a naïve assumption 😂 (See what I did in that sentence?)
>>
>> Was removal of these words introduced for SEO reasons?
>>>
>>
>> Seems likely.
>>
>> Personally, for the reasons you've presented I think it would make sense
>> to remove this behaviour. We can probably document how to wrap
>> window.URLify to preserve the old behaviour.
>>
>> On Wed, 8 Apr 2020 at 20:38, Andy Chosak  wrote:
>>
>>> Automatic slug generation in ModelAdmin via prepopulated_fields
>>> 
>>> uses a urlify.js
>>> 
>>> file which, among other behaviors, removes certain stop words
>>> 
>>> from the slug. For example, a string like "To be or not to be, that is the
>>> question" will generate a slug "be-or-not-be-question", not
>>> "to-be-or-not-to-be-that-is-the-question" as one might expect. I’d like to
>>> solicit feedback on the idea of removing this logic so that slugs can
>>> contain these words.
>>>
>>> For reference, the current list is: a, an, as, at, before, but, by, for,
>>> from, is, in, into, like, of, off, on, onto, per, since, than, the, this,
>>> that, to, up, via, with.
>>>
>>> Django ticket #30538 
>>> mentions this behavior as part of a more general comparison between
>>> urlify.js and Python slugify
>>> .
>>> It was closed as wontfix due to reasons of backwards compatibility. Per the 
>>> triaging
>>> guidelines
>>> ,
>>> I’m making this post to solicit feedback on the more specific question of
>>> addressing stopword removal in the JS code only -- not to try to address
>>> any other differences in behavior between these two methods. There’s been
>>> quite a bit of discussion on generating slugs for non-English languages
>>> (for example #2282 ), and
>>> this post is not intended to reopen that discussion.
>>>
>>> The current list of stopwords being removed seems to have been the same 
>>> since
>>> at least 2005
>>> 
>>> (the earliest code I can find including this logic). Some of these words
>>> feel a little unexpected, for example “before” and “since”. After 15 years
>>> it seems reasonable to revisit the list and consider whether it still makes
>>> sense.
>>>
>>> Was removal of these words introduced for SEO reasons? If so, is this
>>> still a recommended default behavior? In 2020, search engines like Google
>>> seem smart enough to interpret them properly. Here's
>>>  an arbitrary page that
>>> discusses this and includes a much longer list of what might be considered
>>> stopwords. As another datapoint, the popular WordPress Y

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

[Mariusz Felisiak]

`models.NullBooleanField` is now deprecated [1].

I would like to ask again about opinions on deprecating `forms.
NullBooleanField` because I'm not convinced that it's necessary and 
expected. `forms.NullBooleanField` and `forms.BooleanField` use different 
widgets and their behavior is slightly different. Personally, I agree with 
Tim [2] that removing `forms.NullBooleanField` will needlessly increase 
complexity.

Best,
Mariusz

[1] 
https://github.com/django/django/commit/a92cc84b4a206d18a5f1a0eaa47f19add40ff99b
[2] https://github.com/django/django/pull/12636#pullrequestreview-383329786

-- 
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/9a3fba1b-79e0-4ff1-8105-6ad5dd9e5458%40googlegroups.com.

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

[Adam Johnson]

I'm -1 on deprecating the form field. The different widgets make sense.
Forms are decoupled from models for reasons like this.

On Fri, 24 Apr 2020 at 11:39, Mariusz Felisiak 
wrote:

> `models.NullBooleanField` is now deprecated [1].
>
> I would like to ask again about opinions on deprecating `forms.
> NullBooleanField` because I'm not convinced that it's necessary and
> expected. `forms.NullBooleanField` and `forms.BooleanField` use different
> widgets and their behavior is slightly different. Personally, I agree with
> Tim [2] that removing `forms.NullBooleanField` will needlessly increase
> complexity.
>
> Best,
> Mariusz
>
> [1]
> https://github.com/django/django/commit/a92cc84b4a206d18a5f1a0eaa47f19add40ff99b
> [2]
> https://github.com/django/django/pull/12636#pullrequestreview-383329786
>
> --
> 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/9a3fba1b-79e0-4ff1-8105-6ad5dd9e5458%40googlegroups.com
> 
> .
>


-- 
Adam

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

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

[charettes]

I'm also -1 on removing the form field for the same reasons as Adam.

Le vendredi 24 avril 2020 06:39:06 UTC-4, Mariusz Felisiak a écrit :
>
> `models.NullBooleanField` is now deprecated [1].
>
> I would like to ask again about opinions on deprecating `forms.
> NullBooleanField` because I'm not convinced that it's necessary and 
> expected. `forms.NullBooleanField` and `forms.BooleanField` use different 
> widgets and their behavior is slightly different. Personally, I agree with 
> Tim [2] that removing `forms.NullBooleanField` will needlessly increase 
> complexity.
>
> Best,
> Mariusz
>
> [1] 
> https://github.com/django/django/commit/a92cc84b4a206d18a5f1a0eaa47f19add40ff99b
> [2] 
> https://github.com/django/django/pull/12636#pullrequestreview-383329786
>

-- 
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/2cb62a54-6493-4acb-a75c-0b59fca23128%40googlegroups.com.

Re: Deadlock bug in logging? Reproducible case

[René Fleschenberg]

Hi,

On 4/23/20 12:20 PM, Adam Johnson wrote:
> What version of Python René?

I tested with 3.6.7. I can test with other versions, if that helps.

Regards,
René



-- 
René Fleschenberg

-- 
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/238fdf4b-fb01-f2b8-bbc1-ef065c0ebd63%40fleschenberg.net.

Re: Deadlock bug in logging? Reproducible case

[Brian Tiemann]

Nah, I'm good — but thank you!


On Friday, April 24, 2020 at 8:57:09 AM UTC-4, René Fleschenberg wrote:
>
> Hi, 
>
> On 4/23/20 12:20 PM, Adam Johnson wrote: 
> > What version of Python René? 
>
> I tested with 3.6.7. I can test with other versions, if that helps. 
>
> Regards, 
> René 
>
>
>
> -- 
> René Fleschenberg 
>
>

-- 
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/090de7e4-8d00-4432-85cc-95bdd7424988%40googlegroups.com.

Re: Generate JWTs with Django

[Markus Holtermann]

Nice work, Claude!

However, dealing with JWTs, and especially verifying them is notoriously hard 
and fragile. Frankly, I think I'd rather see smaller libraries do one job and 
do it well, than having Django implement an incomplete JWT spec. As far as I 
can tell, only HS256 signing/verification is implemented, but nothing else, 
right?

Cheers,

Markus

On Wed, Apr 22, 2020, at 3:38 PM, Adam Johnson wrote:
> Hi Claude
> 
> JWT's are indeed popular for API's. I think if Django was being created 
> "from the ground up" today, JWT's would be a no-brainer to include, so 
> it seems reasonable to add some support.
> 
> I've had a look at the PR, and yes it is indeed a small amount of code 
> - and thanks for the documentation.
> 
> Have you got any data on how often encrypted vs. non-encrypted JWT's 
> are used? Personally I can't remember from the projects I've worked on 
> which format has been used.
> 
> Thanks,
> 
> Adam
> 
> On Wed, 22 Apr 2020 at 09:57, Claude Paroz  wrote:
> > For your information, I now added docs to the tentative patch:
> > 
> > https://github.com/django/django/pull/12728
> > 
> >  Claude
> > 
> >  Le 15.04.20 à 21:26, Claude Paroz a écrit :
> >  > Thanks Abhijeet for the pointer, I know there are some rather complete
> >  > JWT libs around, but my proposal is not about a complete package to
> >  > manage JWT in general.
> >  > It's rather some low level ability for Django to produce and decode
> >  > simple HS256 JWT. Then other third-party libs could build on that
> >  > ability to write more elaborate packages.
> >  > 
> >  > The main doubt I have about my proposal is whether HS256 JWTs are too
> >  > limited for most usages or in the contrary if they are appropriate for a
> >  > fair amount of use cases.
> >  > 
> >  > Claude
> >  > 
> >  > Le 15.04.20 à 21:13, Abhijeet Viswa a écrit :
> >  >> Hi,
> >  >>
> >  >> You might want check out django-restframework-simplejwt. It requires the
> >  >> Django Rest Framework. But, then again, if you are making an API, you'd
> >  >> already be using it.
> >  >>
> >  >> Regards,
> >  >> Abhijeet
> >  >>
> >  >> On Thu, 16 Apr, 2020, 00:39 Claude Paroz,  >  >> > wrote:
> >  >>
> >  >> Hi all,
> >  >>
> >  >> With the recent addition of the algorithm parameter to the
> >  >> signing.Signer class, it's now rather straightforward for Django to
> >  >> generate HS256 (non-encrypted) JSON Web Tokens.
> >  >> With a growing popularity of JS-client/Django server communications
> >  >> (DRF and al.), I think there might be some interest for Django to be
> >  >> able to generate and decode such tokens. For any other types of JWTs
> >  >> which generally require access to a cryptography module, we can
> >  >> point users to third-party libs like PyJWT (the docs should be clear
> >  >> about that).
> >  >>
> >  >> I made a proof-of-concept PR (docs missing) here:
> >  >> - https://github.com/django/django/pull/12728
> >  >>
> >  >> What people here think about that proposal?
> >  >>
> >  >> Claude
> > 
> >  -- 
> >  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/87ddf575-0756-b99e-51d8-99de1b258c21%402xlibre.net.
> 
> 
> -- 
> 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/CAMyDDM2x%3D%2BB0xM0YRauHxwDDm2ymxeGmYqYCVdOMJS94-F4Xdg%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/bb569a66-38d5-4165-8da9-fa0cd6a799da%40www.fastmail.com.

Seamless Application Failover using libpq

[f.holop]

hello,

i was wondering if there was any work done/planned/discussed about
implementing support for this really useful feature of libpq:

$ psql 
'postgres://host1:5432,host2:5432,host3:5432/postgres?target_session_attrs=read-write'

Psycopg claims to support all dsn parameters.


https://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/


https://www.postgresql.org/docs/12/libpq-connect.html

target_session_attrs

If this parameter is set to read-write, only a connection in which
read-write transactions are accepted by default is considered
acceptable. The query SHOW transaction_read_only will be sent upon
any successful connection; if it returns on, the connection will be
closed. If multiple hosts were specified in the connection string,
any remaining servers will be tried just as if the connection
attempt had failed. The default value of this parameter, any,
regards all connections as acceptable.



this has the potential of making failover possible without any
additional software.

a quick search through the tickets and PRs brought up no results.

-f
-- 

-- 
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/20200424085821.GA87143%40obiit.org.

Re: Generate JWTs with Django

[Claude Paroz]

Hey Markus,

In fact, when I had to implement that in one of my projects, I realized 
that Django has already most tools needed to (in my opinion) properly 
handle those tokens. And indeed, this only covers HS256-type of JWTs, for 
any other type, we would recommend using a third-party package (see the 
docs type of my patch).
If we had to reimplement all the hard work of signing and verifying, I 
would not have proposed this addition to Django.

Claude

Le vendredi 24 avril 2020 16:32:27 UTC+2, Markus Holtermann a écrit :
>
> Nice work, Claude! 
>
> However, dealing with JWTs, and especially verifying them is notoriously 
> hard and fragile. Frankly, I think I'd rather see smaller libraries do one 
> job and do it well, than having Django implement an incomplete JWT spec. As 
> far as I can tell, only HS256 signing/verification is implemented, but 
> nothing else, right? 
>
> Cheers, 
>
> Markus 
>
> On Wed, Apr 22, 2020, at 3:38 PM, Adam Johnson wrote: 
> > Hi Claude 
> > 
> > JWT's are indeed popular for API's. I think if Django was being created 
> > "from the ground up" today, JWT's would be a no-brainer to include, so 
> > it seems reasonable to add some support. 
> > 
> > I've had a look at the PR, and yes it is indeed a small amount of code 
> > - and thanks for the documentation. 
> > 
> > Have you got any data on how often encrypted vs. non-encrypted JWT's 
> > are used? Personally I can't remember from the projects I've worked on 
> > which format has been used. 
> > 
> > Thanks, 
> > 
> > Adam 
> > 
> > On Wed, 22 Apr 2020 at 09:57, Claude Paroz  > wrote: 
> > > For your information, I now added docs to the tentative patch: 
> > > 
> > > https://github.com/django/django/pull/12728 
> > > 
> > >  Claude 
> > > 
> > >  Le 15.04.20 à 21:26, Claude Paroz a écrit : 
> > >  > Thanks Abhijeet for the pointer, I know there are some rather 
> complete 
> > >  > JWT libs around, but my proposal is not about a complete package to 
> > >  > manage JWT in general. 
> > >  > It's rather some low level ability for Django to produce and decode 
> > >  > simple HS256 JWT. Then other third-party libs could build on that 
> > >  > ability to write more elaborate packages. 
> > >  > 
> > >  > The main doubt I have about my proposal is whether HS256 JWTs are 
> too 
> > >  > limited for most usages or in the contrary if they are appropriate 
> for a 
> > >  > fair amount of use cases. 
> > >  > 
> > >  > Claude 
> > >  > 
> > >  > Le 15.04.20 à 21:13, Abhijeet Viswa a écrit : 
> > >  >> Hi, 
> > >  >> 
> > >  >> You might want check out django-restframework-simplejwt. It 
> requires the 
> > >  >> Django Rest Framework. But, then again, if you are making an API, 
> you'd 
> > >  >> already be using it. 
> > >  >> 
> > >  >> Regards, 
> > >  >> Abhijeet 
> > >  >> 
> > >  >> On Thu, 16 Apr, 2020, 00:39 Claude Paroz,   
> > >  >> > wrote: 
> > >  >> 
> > >  >> Hi all, 
> > >  >> 
> > >  >> With the recent addition of the algorithm parameter to the 
> > >  >> signing.Signer class, it's now rather straightforward for Django 
> to 
> > >  >> generate HS256 (non-encrypted) JSON Web Tokens. 
> > >  >> With a growing popularity of JS-client/Django server 
> communications 
> > >  >> (DRF and al.), I think there might be some interest for Django to 
> be 
> > >  >> able to generate and decode such tokens. For any other types of 
> JWTs 
> > >  >> which generally require access to a cryptography module, we can 
> > >  >> point users to third-party libs like PyJWT (the docs should be 
> clear 
> > >  >> about that). 
> > >  >> 
> > >  >> I made a proof-of-concept PR (docs missing) here: 
> > >  >> - https://github.com/django/django/pull/12728 
> > >  >> 
> > >  >> What people here think about that proposal? 
> > >  >> 
> > >  >> Claude 
>

-- 
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/3d7304c8-79d7-4ea5-a602-15131f85b7ee%40googlegroups.com.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Adam Johnson]

>
> But I read Andrew's comment differently: it's maybe not the 60 characters,
> but some sort of "aggregation" we could be looking for. So maybe instead of
> "0026_remove_book_title_add_book_description" we could have
> "0026_book_add_remove" - especially when multiple fields were involved.


I feel an implementation for anything like this would be very complicated,
especially when factoring in RunPython, RunSQL, and custom operations. I
don't think it's worth the effort, considering that it's a best "first
guess" for the name, and developers can change them if they feel they
aren't descriptive (though the point of this change is that they often
don't).

> Alternatively, makemigrations could also generate multiple migrations (by
> default?) in order to obtain the goal of meaningful names? Have a parameter
> to force combining?
>
I don't think that's ideal because migrations are atomic (by default) on
databases that support atomic DDL. Splitting them for the sake of slightly
better automatic naming unnecessarily breaks this guarantee.

On Fri, 24 Apr 2020 at 08:32, Jure Erznožnik 
wrote:

> I too am in favour of this change.
>
> But I read Andrew's comment differently: it's maybe not the 60 characters,
> but some sort of "aggregation" we could be looking for. So maybe instead of
> "0026_remove_book_title_add_book_description" we could have
> "0026_book_add_remove" - especially when multiple fields were involved.
>
> Alternatively, makemigrations could also generate multiple migrations (by
> default?) in order to obtain the goal of meaningful names? Have a parameter
> to force combining?
>
> LP,
> Jure
> On 23/04/2020 21:34, Adam Johnson wrote:
>
> Thank you all for the feedback.
>
> Re: Andrew:
>
>> (60 is a bit long though, maybe we can bump it down to something a bit
>> shorter?)
>>
>
> Sure, how about 42? 👽
>
> Re: Jon:
>
>> Did you have a suggestion for this situation? Revert back to auto-naming
>> or request the user to name the migration?
>>
>
> The patch as-is accumulates suggested names from operations in order,
> until the length is >=60 characters. Later operations just aren't mentioned.
>
> Re: Claude:
>
>> An alternative could be to ask the user in interactive mode (and keep the
>> current behaviour in non-interactive mode).
>>
>
> I'd be up for this if we "pre-fill" the input with the auto-generated
> name, to make it easy to continue when we can suggest a reasonable name.
> Forcing users to type a name from scratch could be annoying especially when
> iterating on a new feature and dropping/rebuilding the respective migration.
>
> Re: Caio:
>
>> I work on a project where migration names are fixed to “auto”. We use a
>> similar technique to those mentioned in the blog post to do that. The
>> reason is that we want to force developers to get conflicts (git) on
>> migration names during the review process, rather than having to handle
>> migration merging manually during deploy
>
>
> Yes, this is a secondary problem with migrations, trying to keep the
> history linear via git.
>
> I've used an alternative solution where a second file is created in the
> migrations folder called "latest" or similar, that simply contains the name
> of the latest migration file. This forces a conflict.
>
> Although that's an alternative proposal, I think adding something like
> that to Django could be a good idea. It's better than forcing all
> migrations to have meaningless names.
>
>
> On Wed, 22 Apr 2020 at 16:47, Andrew Godwin  wrote:
>
>> I am a little mixed on this change - the behaviour during the initial
>> development was indeed to concatenate names like this, albeit only for
>> adding fields or models; I thought it looked unwieldy, which is why I added
>> the "auto" name.
>>
>> That said, the number is the only part that actually matters, and while
>> the date is sometimes useful for people to resolve merge conflicts, I don't
>> think it's better than more informative autogenerated names, so I'm happy
>> to go with the change.
>>
>> (60 is a bit long though, maybe we can bump it down to something a bit
>> shorter?)
>>
>> Andrew
>>
>> On Wed, Apr 22, 2020 at 7:06 AM Adam Johnson  wrote:
>>
>>> Hi djangonauts,
>>>
>>> In a blog post earlier this year I outlined my technique to prevent
>>> Django creating migration files with automatic date names. I had a lot of
>>> response with other techniques and ended up adding two more techniques to
>>> the post. It's at
>>> https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
>>> .
>>>
>>> The problem with such migration names:
>>>
>>> When you run Django’s manage.py makemigrations, it will try to generate
 a name for the migration based upon its contents. For example, if you are
 adding a single field, it will call the migration
 0002_mymodel_myfield.py. However when your migration contains more
 than one step, it instead uses a simple ‘auto’ name with the current date +
 time, e.g. 0002_auto_20200113_1837.py. You can prov