Opened 3 years ago

Last modified 3 years ago

#23953 assigned Cleanup/optimization

makemigrations generates "wrong" numbered migration file if squashed migrations are in place

Reported by: Markus Holtermann Owned by: Sergey
Component: Migrations Version: 1.7
Severity: Normal Keywords:
Cc: Markus Holtermann Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When an app has migrations 0001_initial and 0002_auto_20141202_1234 that are squashed to 0001_squashed_0002_auto_20141202_1234, a new call to makemigrations will generate a migration file called 0002_auto_20141202_2345 instead of 0003_auto_20141202_2345 which is quite irritating as long as 0002_auto_20141202_1234 is still around. It does make sense though when only 0001_squashed_0002_auto_20141202_1234 is left.

Although the latter case eventually hits every project, I'd prefer the former.

Change History (4)

comment:1 Changed 3 years ago by Tim Graham

Based on your logic, is it irritating to have 0001_initial and 0001_squashed_0002_auto_20141202_1234? Should the first squashed migration be 0003_...?

comment:2 Changed 3 years ago by Markus Holtermann

I don't think so. The squashed migration replaces 0001 to 0002, so sticking to 0001 seems fine to me.

Rethinking the initial thought about 0002_auto_20141202_2345 making sense if 0002_auto_20141202_1234 is gone an only the squashed migration is around: no, it doesn't make sense. The squashed migration says "0001 to 0002 is squashed". Thus continuing with 0003 seems to be the right choice.

comment:3 Changed 3 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

I guess it makes sense. If there is no way to reset the sequence of migrations, I wonder what happens when app has 10K migrations.

comment:4 Changed 3 years ago by Sergey

Owner: changed from nobody to Sergey
Status: newassigned
Note: See TracTickets for help on using tickets.
Back to Top