Re: Django "makemigrations -- update" donot working

[David Wobrock]

Hi,

As you can see, the error message seems quite clear:
> Cannot update applied migration 'authentication.0001_initial'.
One cannot edit a migration that has already been applied.
To update it, you can undo it by running "migrate authentication zero" and
then run "makemigrations --update" again.

I do not think it's a bug in Django.

Cheers,
David

Le sam. 8 avr. 2023 à 16:50, Muhammad Juwaini Abdul Rahman <
juwa...@gmail.com> a écrit :

> Do you need that '--update' parameter?
>
> On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen 
> wrote:
>
>> in my custom user model, initially, my model looks like this
>>
>> class User(AbstractUser, BaseModelWithUUID):
>> phone = models.CharField(max_length=11,
>> validators=[validate_phone_number])
>> I do command "makemigrations" which create a initial migration file
>>
>> but after updating my model like this
>>
>> class User(AbstractUser, BaseModelWithUUID):
>> phone = models.CharField(max_length=11,
>> validators=[validate_phone_number])
>> name = models.CharField(max_length=255)
>>
>> after adding a field "name" when i run "makemigrations --update" it shows
>> a error:
>>
>> CommandError: Cannot update applied migration
>> 'authentication.0001_initial'.
>>
>> --
>> 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/793fee18-1231-456b-8d91-f976bebad5e2n%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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%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/CAHS_w9bXLJ0Cj30yU%2BLw%2BATofw%2B-kkeH2NYF8YCcv6ax303xeg%40mail.gmail.com.

Re: Integrating migrations with the check framework

[David Wobrock]

Hi everyone,

I agree that there is room for improvement around migrations in Django 
with respect to the expected downtime/table locking. But I don’t know 
whether this should in Django itself or handled by a 3rd party library.


I’m maintaining the django-migration-linter (the very idea was to have 
an automated tool since reviewing migrations is not something new Django 
devs can do easily), which currently tackles another issue than the one 
you mention. It tries, in a best effort manner as you’ve seen through 
the SQL checks, to understand if the migration is introducing a backward 
incompatible change to your schema, which will desynchronize your code 
and database schema (so you’ll get errors when you deploy one without 
the other – and you’ll have a hard time doing a rollback).


It’s a different aspect, compared to checking that the forward migration 
will be instant and non-locking. However, it is planned to add this to 
the linter too 
(https://github.com/3YOURMIND/django-migration-linter/issues/99 
).


You’ve noticed that it’s based on the SQL strings, which has advantages 
and drawbacks. The checks are easy to implement (just a set of rules 
basically), it could be completely Django-agnostic and it can lint 
RunSQL operations. But it’s a bit harder to represent a state when 
multiple SQL statements are executed, to check if they cancel each other 
out for instance.


An idea about something that could be in Django would be, somehow like 
the “database features”, marking for each migration operation 
(AlterField, AddField, …) on each database backend, if they can 
potentially mean downtime. It would be a hint about the risk of the 
migration, and display a warning if necessary.*
*Going one step further, for some operations, Django could query the 
number of rows of the corresponding table and have some risk heuristics. 
Basically: “you’re adding a column to a table with less than 100 rows, 
this should not be risky” or “you’re adding a column to a table with 
millions of rows, be careful!”.
However, as these heuristics would be rather arbitrary, I’m not sure 
that the Django project would want to make this kind of choices – so it 
might be a better fit for a library. (what I’m describing is more or 
less the ultimate goal the django-migration-linter)


Hope this gives some insights about the project and how it could help on 
this topic :)


Cheers,
David


On 23/12/2020 19:02, Tom Forbes wrote:

Thanks for all the input here!

I didn’t know about django-migration-linter, and it does seem quite 
interesting. It works by looking at the complete set of SQL statements 
that would be run, and running regular expressions/string comparisons 
on it 
(https://github.com/3YOURMIND/django-migration-linter/blob/master/django_migration_linter/sql_analyser/base.py#L59-L62 
). 
I don’t hate this idea, but I think that having direct access to the 
migration objects themselves could greatly simplify the implementation.


Django-pg-zero-downtime-migrations also looks interesting and is more 
in-line with what I was imagining 
(https://github.com/tbicr/django-pg-zero-downtime-migrations/blob/master/django_zero_downtime_migrations/backends/postgres/schema.py 
) 
- it overrides the schema editor to detect unsafe migrations, and 
provides a nice way to abort migrations that take locks for too long. 
However I feel that the implementation could be greatly simplified 
with some support for Django - you shouldn’t really need to override 
the schema editor, Django should pass you a list of operations and ask 
“is this safe?”. The results can be reported via the checks framework 
which allows application owners can decide to treat these warnings as 
errors or silence them as needed. It also brings those warnings 
front-and-centre while developing, rather than having it fail when 
running “migrate” later on in the deployment process.


Django-safemigrate is very related and something I wanted to cover in 
a later message. I feel that some of this functionality could (or even 
should) be integrated with Django, as migrations in “real” apps are 
usually a two step process: you run the schema migrations, which might 
add a nullable column, deploy your app, then run data migrations to 
populate the column. At least bringing the concept of a pre-deploy and 
a post-deploy migration to Django would be pretty useful I think.


I’d say the open questions so far are:

 1. Does it make sense to add a specific system check registration
function for migrations? If not, how do we expose this to users
wishing to write system checks?
 2. Are we comfortable with creating a public API for some of the
migrations inte