마이그레이션은 당신의 모델에 생긴 변화(필드를 추가했다던가 모델을 삭제했다던가 등등)를 반영하는 Django의 방식입니다. 대체로 자동실행되도록 설계되었지만 언제 마이그레이션을 만들고 언제 실행하고 보통 어떤 문제에 맞닥트리는지는 알아둘 필요가 있습니다.
\n마이그레이션을 실행하고 데이터베이스 스키마를 Django가 다루기 위한 다양한 명렁어들이 있습니다:
\nmigrate 은 마이그레이션을 반영하거나 반영하지 않기 위해 사용합니다.
:djadmin:`makemigrations`는 모델을 변경한 것에 기반한 새로운 마이그레이션을 만들 때 사용합니다.
:djadmin:`sqlmigrate`은 마이그레이션을 위한 SQL 구문을 보기 위해 사용합니다.
:djadmin:`showmigrations`는 프로젝트 전체의 마이그레이션과 각각의 상태를 나열하기 위해 사용합니다.
마이그레이션은 당신이 다루고 있는 데이터베이스 스키마를 위한 버전 관리 시스템(VCS)이라고 생각하면 됩니다. ``makemigrations``는 모델에 생긴 변화를-깃의 커밋과 유사하게-개별 마이그레이션 파일에 싸넣는 작업입니다. ``migrate``는 각각의 마이그레이션 파일을 데이터베이스에 적용하는 작업입니다.
\n각 앱의 마이그레이션 파일들은 해당 앱의 “migrations” 디렉토리 안에 있습니다. 마이그레이션 파일은 앱의 코드베이스에 적용되어 앱의 각 부분에 분배되도록 설계되어 있습니다. 마이그레이션 파일을 개발 기기에서 한 번 만들고 동료들의 기기, 스테이징 기기(개발 서버에서 운영 서버로 넘어가기 전에 운영 서버와 유사한 환경으로 테스트하는 서버) 그리고 최종적으로는 운영 기기에서 같은 마이그레이션 파일을 실행하면 됩니다.
\n\n마이그레이션은 같은 데이터셋에서 똑같이 작동할 것이고 똑같은 결과물을 만들어낼 것입니다. 즉 같은 상황이라면 개발이나 스테이징에서 봤던 것과 정확하게 똑같은 결과물이 운영 단계에서 나온다는 말입니다.
\n마치 정확하게 필드를 재구축하는 유일한 방법이 모든 변화를 기록해놓는 것인냥 Django는 모델과 필드에서 생기는 모든 변화에 대해서 마이그레이션을 만들 것입니다. 심지어 데이터베이스에 영향을 못 미치게 하는 옵션을 켜더라도 일단은 만들 것입니다. 나중에 다룰 데이터 마이그레이션에서 이런 옵션도 필요할 것입니다.(예를 들면 커스텀 검사기를 설정해놓았다거나.)
\n스키마 변화를 지원하도록 만들어진(SchemaEditor 1 클래스 문서 참조). 서드파티 백엔드를 포함해서, Django에 포함된 모든 백엔드에서 마이그레이션이 지원됩니다.
\n하지만 일부 데이터베이스가 스키마 마이그레이션에 있어서 다른 것들보다 더 용이합니다. 특징들은 아래에서 다루겠습니다.
\nPostgreSQL is the most capable of all the databases here in terms of schema\nsupport.
\nMySQL은 스키마 변환 작업을 할 때 트랜잭션에 대한 지원이 부족합니다. 만약 마이그레이션 적용에 실패하면 재시도하기 위해 수동으로 변경사항을 취소해야 합니다.(즉 이전으로 롤백하는 것이 불가능합니다)
\nMySQL 8.0 introduced significant performance enhancements for\nDDL operations, making them more efficient and reducing the need for full\ntable rebuilds. However, it cannot guarantee a complete absence of locks or\ninterruptions. In situations where locks are still necessary, the duration of\nthese operations will be proportionate to the number of rows involved.
\nFinally, MySQL has a relatively small limit on the combined size of all columns\nan index covers. This means that indexes that are possible on other backends\nwill fail to be created under MySQL.
\nSQLite는 매우 한정된 스키마 변동만 자체적으로 지원해서 Django가 아래 방법으로 스키마 변동을 흉내냅니다.
\n새 스키마로 새 테이블 만들기
테이블 간의 데이터 복사
기존 테이블 삭제
새 테이블의 이름을 기존 테이블의 이름으로 변경
이 방법은 보통 잘 작동하지만 속도가 느리고 종종 버그가 납니다. 위험과 한계를 정확하게 알지 않는 이상 운영 환경에서 SQLite로 운영하거나 마이그레이션 하는 것을 추천하지 않습니다. Django에서는 개발자들에게 로컬 장비에서 완전한 데이터베이스가 필요하지 않은 간단한 Django 프로젝트를 할 때만 SQLite를 쓰는 것을 허용하도록 지원하고 있습니다.
\nDjango can create migrations for you. Make changes to your models - say, add a\nfield and remove a model - and then run makemigrations:
$ python manage.py makemigrations\nMigrations for 'books':\n books/migrations/0003_auto.py:\n ~ Alter field author on book\nYour models will be scanned and compared to the versions currently\ncontained in your migration files, and then a new set of migrations\nwill be written out. Make sure to read the output to see what\nmakemigrations thinks you have changed - it’s not perfect, and for\ncomplex changes it might not be detecting what you expect.
Once you have your new migration files, you should apply them to your\ndatabase to make sure they work as expected:
\n$ python manage.py migrate\nOperations to perform:\n Apply all migrations: books\nRunning migrations:\n Rendering model states... DONE\n Applying books.0003_auto... OK\nOnce the migration is applied, commit the migration and the models change\nto your version control system as a single commit - that way, when other\ndevelopers (or your production servers) check out the code, they’ll\nget both the changes to your models and the accompanying migration at the\nsame time.
\nIf you want to give the migration(s) a meaningful name instead of a generated\none, you can use the makemigrations --name option:
$ python manage.py makemigrations --name changed_my_model your_app_label\nBecause migrations are stored in version control, you’ll occasionally\ncome across situations where you and another developer have both committed\na migration to the same app at the same time, resulting in two migrations\nwith the same number.
\nDon’t worry - the numbers are just there for developers’ reference, Django\njust cares that each migration has a different name. Migrations specify which\nother migrations they depend on - including earlier migrations in the same\napp - in the file, so it’s possible to detect when there’s two new migrations\nfor the same app that aren’t ordered.
\nWhen this happens, Django will prompt you and give you some options. If it\nthinks it’s safe enough, it will offer to automatically linearize the two\nmigrations for you. If not, you’ll have to go in and modify the migrations\nyourself - don’t worry, this isn’t difficult, and is explained more in\nMigration files below.
\nOn databases that support DDL transactions (SQLite and PostgreSQL), all\nmigration operations will run inside a single transaction by default. In\ncontrast, if a database doesn’t support DDL transactions (e.g. MySQL, Oracle)\nthen all operations will run without a transaction.
\nYou can prevent a migration from running in a transaction by setting the\natomic attribute to False. For example:
from django.db import migrations\n\n\nclass Migration(migrations.Migration):\n atomic = False\nIt’s also possible to execute parts of the migration inside a transaction using\natomic() or by passing atomic=True to\nRunPython. See\n비원자성 마이그레이션입니다. for more details.
While migrations are per-app, the tables and relationships implied by\nyour models are too complex to be created for one app at a time. When you make\na migration that requires something else to run - for example, you add a\nForeignKey in your books app to your authors app - the resulting\nmigration will contain a dependency on a migration in authors.
This means that when you run the migrations, the authors migration runs\nfirst and creates the table the ForeignKey references, and then the migration\nthat makes the ForeignKey column runs afterward and creates the constraint.\nIf this didn’t happen, the migration would try to create the ForeignKey\ncolumn without the table it’s referencing existing and your database would\nthrow an error.
This dependency behavior affects most migration operations where you\nrestrict to a single app. Restricting to a single app (either in\nmakemigrations or migrate) is a best-efforts promise, and not\na guarantee; any other apps that need to be used to get dependencies correct\nwill be.
Apps without migrations must not have relations (ForeignKey,\nManyToManyField, etc.) to apps with migrations. Sometimes it may work, but\nit’s not supported.
The swappable_dependency() function is used in migrations to declare\n“swappable” dependencies on migrations in the app of the swapped-in model,\ncurrently, on the first migration of this app. As a consequence, the swapped-in\nmodel should be created in the initial migration. The argument value is a\nstring "<app label>.<model>" describing an app label and a model name, e.g.\n"myapp.MyModel".
By using swappable_dependency(), you inform the migration framework that\nthe migration relies on another migration which sets up a swappable model,\nallowing for the possibility of substituting the model with a different\nimplementation in the future. This is typically used for referencing models\nthat are subject to customization or replacement, such as the custom user\nmodel (settings.AUTH_USER_MODEL, which defaults to "auth.User") in\nDjango’s authentication system.
Migrations are stored as an on-disk format, referred to here as\n“migration files”. These files are actually normal Python files with an\nagreed-upon object layout, written in a declarative style.
\nA basic migration file looks like this:
\nfrom django.db import migrations, models\n\n\nclass Migration(migrations.Migration):\n dependencies = [("migrations", "0001_initial")]\n\n operations = [\n migrations.DeleteModel("Tribble"),\n migrations.AddField("Author", "rating", models.IntegerField(default=0)),\n ]\nWhat Django looks for when it loads a migration file (as a Python module) is\na subclass of django.db.migrations.Migration called Migration. It then\ninspects this object for four attributes, only two of which are used\nmost of the time:
dependencies, a list of migrations this one depends on.
operations, a list of Operation classes that define what this\nmigration does.
The operations are the key; they are a set of declarative instructions which\ntell Django what schema changes need to be made. Django scans them and\nbuilds an in-memory representation of all of the schema changes to all apps,\nand uses this to generate the SQL which makes the schema changes.
\nThat in-memory structure is also used to work out what the differences are\nbetween your models and the current state of your migrations; Django runs\nthrough all the changes, in order, on an in-memory set of models to come\nup with the state of your models last time you ran makemigrations. It\nthen uses these models to compare against the ones in your models.py files\nto work out what you have changed.
You should rarely, if ever, need to edit migration files by hand, but\nit’s entirely possible to write them manually if you need to. Some of the\nmore complex operations are not autodetectable and are only available via\na hand-written migration, so don’t be scared about editing them if you have to.
\nYou can’t modify the number of positional arguments in an already migrated\ncustom field without raising a TypeError. The old migration will call the\nmodified __init__ method with the old signature. So if you need a new\nargument, please create a keyword argument and add something like\nassert 'argument_name' in kwargs in the constructor.
You can optionally serialize managers into migrations and have them available\nin RunPython operations. This is done\nby defining a use_in_migrations attribute on the manager class:
class MyManager(models.Manager):\n use_in_migrations = True\n\n\nclass MyModel(models.Model):\n objects = MyManager()\nIf you are using the from_queryset() function to\ndynamically generate a manager class, you need to inherit from the generated\nclass to make it importable:
class MyManager(MyBaseManager.from_queryset(CustomQuerySet)):\n use_in_migrations = True\n\n\nclass MyModel(models.Model):\n objects = MyManager()\nPlease refer to the notes about Historical models in migrations to see\nthe implications that come along.
\nThe “initial migrations” for an app are the migrations that create the first\nversion of that app’s tables. Usually an app will have one initial migration,\nbut in some cases of complex model interdependencies it may have two or more.
\nInitial migrations are marked with an initial = True class attribute on the\nmigration class. If an initial class attribute isn’t found, a migration\nwill be considered “initial” if it is the first migration in the app (i.e. if\nit has no dependencies on any other migration in the same app).
When the migrate --fake-initial option is used, these initial\nmigrations are treated specially. For an initial migration that creates one or\nmore tables (CreateModel operation), Django checks that all of those tables\nalready exist in the database and fake-applies the migration if so. Similarly,\nfor an initial migration that adds one or more fields (AddField operation),\nDjango checks that all of the respective columns already exist in the database\nand fake-applies the migration if so. Without --fake-initial, initial\nmigrations are treated no differently from any other migration.
As previously discussed, you may need to linearize migrations manually when two\ndevelopment branches are joined. While editing migration dependencies, you can\ninadvertently create an inconsistent history state where a migration has been\napplied but some of its dependencies haven’t. This is a strong indication that\nthe dependencies are incorrect, so Django will refuse to run migrations or make\nnew migrations until it’s fixed. When using multiple databases, you can use the\nallow_migrate() method of database routers to control which databases\nmakemigrations checks for consistent history.
New apps come preconfigured to accept migrations, and so you can add migrations\nby running makemigrations once you’ve made some changes.
If your app already has models and database tables, and doesn’t have migrations\nyet (for example, you created it against a previous Django version), you’ll\nneed to convert it to use migrations by running:
\n$ python manage.py makemigrations your_app_label\nThis will make a new initial migration for your app. Now, run python\nmanage.py migrate --fake-initial, and Django will detect that you have an\ninitial migration and that the tables it wants to create already exist, and\nwill mark the migration as already applied. (Without the migrate\n--fake-initial flag, the command would error out because the tables it wants\nto create already exist.)
Note that this only works given two things:
\nYou have not changed your models since you made their tables. For migrations\nto work, you must make the initial migration first and then make changes,\nas Django compares changes against migration files, not the database.
You have not manually edited your database - Django won’t be able to detect\nthat your database doesn’t match your models, you’ll just get errors when\nmigrations try to modify those tables.
Migrations can be reversed with migrate by passing the number of the\nprevious migration. For example, to reverse migration books.0003:
Linux / macOS
$ python manage.py migrate books 0002\nOperations to perform:\n Target specific migration: 0002_auto, from books\nRunning migrations:\n Rendering model states... DONE\n Unapplying books.0003_auto... OK\nWindows
...\\> py manage.py migrate books 0002\nOperations to perform:\n Target specific migration: 0002_auto, from books\nRunning migrations:\n Rendering model states... DONE\n Unapplying books.0003_auto... OK\nIf you want to reverse all migrations applied for an app, use the name\nzero:
Linux / macOS
$ python manage.py migrate books zero\nOperations to perform:\n Unapply all migrations: books\nRunning migrations:\n Rendering model states... DONE\n Unapplying books.0002_auto... OK\n Unapplying books.0001_initial... OK\nWindows
...\\> py manage.py migrate books zero\nOperations to perform:\n Unapply all migrations: books\nRunning migrations:\n Rendering model states... DONE\n Unapplying books.0002_auto... OK\n Unapplying books.0001_initial... OK\nA migration is irreversible if it contains any irreversible operations.\nAttempting to reverse such migrations will raise IrreversibleError:
Linux / macOS
$ python manage.py migrate books 0002\nOperations to perform:\n Target specific migration: 0002_auto, from books\nRunning migrations:\n Rendering model states... DONE\n Unapplying books.0003_auto...Traceback (most recent call last):\ndjango.db.migrations.exceptions.IrreversibleError: Operation <RunSQL sql='DROP TABLE demo_books'> in books.0003_auto is not reversible\nWindows
...\\> py manage.py migrate books 0002\nOperations to perform:\n Target specific migration: 0002_auto, from books\nRunning migrations:\n Rendering model states... DONE\n Unapplying books.0003_auto...Traceback (most recent call last):\ndjango.db.migrations.exceptions.IrreversibleError: Operation <RunSQL sql='DROP TABLE demo_books'> in books.0003_auto is not reversible\nWhen you run migrations, Django is working from historical versions of your\nmodels stored in the migration files. If you write Python code using the\nRunPython operation, or if you have\nallow_migrate methods on your database routers, you need to use these\nhistorical model versions rather than importing them directly.
Because it’s impossible to serialize arbitrary Python code, these historical\nmodels will not have any custom methods that you have defined. They will,\nhowever, have the same fields, relationships, managers (limited to those with\nuse_in_migrations = True) and Meta options (also versioned, so they may\nbe different from your current ones).
References to functions in field options such as upload_to and\nlimit_choices_to and model manager declarations with managers having\nuse_in_migrations = True are serialized in migrations, so the functions and\nclasses will need to be kept around for as long as there is a migration\nreferencing them. Any custom model fields\nwill also need to be kept, since these are imported directly by migrations.
In addition, the concrete base classes of the model are stored as pointers, so\nyou must always keep base classes around for as long as there is a migration\nthat contains a reference to them. On the plus side, methods and managers from\nthese base classes inherit normally, so if you absolutely need access to these\nyou can opt to move them into a superclass.
\nTo remove old references, you can squash migrations\nor, if there aren’t many references, copy them into the migration files.
\nSimilar to the “references to historical functions” considerations described in\nthe previous section, removing custom model fields from your project or\nthird-party app will cause a problem if they are referenced in old migrations.
\nTo help with this situation, Django provides some model field attributes to\nassist with model field deprecation using the system checks framework.
\nAdd the system_check_deprecated_details attribute to your model field\nsimilar to the following:
class IPAddressField(Field):\n system_check_deprecated_details = {\n "msg": (\n "IPAddressField has been deprecated. Support for it (except "\n "in historical migrations) will be removed in Django 1.9."\n ),\n "hint": "Use GenericIPAddressField instead.", # optional\n "id": "fields.W900", # pick a unique ID for your field.\n }\nAfter a deprecation period of your choosing (two or three feature releases for\nfields in Django itself), change the system_check_deprecated_details\nattribute to system_check_removed_details and update the dictionary similar\nto:
class IPAddressField(Field):\n system_check_removed_details = {\n "msg": (\n "IPAddressField has been removed except for support in "\n "historical migrations."\n ),\n "hint": "Use GenericIPAddressField instead.",\n "id": "fields.E900", # pick a unique ID for your field.\n }\nYou should keep the field’s methods that are required for it to operate in\ndatabase migrations such as __init__(), deconstruct(), and\nget_internal_type(). Keep this stub field for as long as any migrations\nwhich reference the field exist. For example, after squashing migrations and\nremoving the old ones, you should be able to remove the field completely.
As well as changing the database schema, you can also use migrations to change\nthe data in the database itself, in conjunction with the schema if you want.
\nMigrations that alter data are usually called “data migrations”; they’re best\nwritten as separate migrations, sitting alongside your schema migrations.
\nDjango can’t automatically generate data migrations for you, as it does with\nschema migrations, but it’s not very hard to write them. Migration files in\nDjango are made up of Operations, and\nthe main operation you use for data migrations is\nRunPython.
To start, make an empty migration file you can work from (Django will put\nthe file in the right place, suggest a name, and add dependencies for you):
\npython manage.py makemigrations --empty yourappname\nThen, open up the file; it should look something like this:
\n# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom django.db import migrations\n\n\nclass Migration(migrations.Migration):\n dependencies = [\n ("yourappname", "0001_initial"),\n ]\n\n operations = []\nNow, all you need to do is create a new function and have\nRunPython use it.\nRunPython expects a callable as its argument\nwhich takes two arguments - the first is an app registry that has the historical versions of all your models\nloaded into it to match where in your history the migration sits, and the\nsecond is a SchemaEditor, which you can use to\nmanually effect database schema changes (but beware, doing this can confuse\nthe migration autodetector!)
Let’s write a migration that populates our new name field with the combined\nvalues of first_name and last_name (we’ve come to our senses and\nrealized that not everyone has first and last names). All we need to do is use\nthe historical model and iterate over the rows:
from django.db import migrations\n\n\ndef combine_names(apps, schema_editor):\n # We can't import the Person model directly as it may be a newer\n # version than this migration expects. We use the historical version.\n Person = apps.get_model("yourappname", "Person")\n for person in Person.objects.all():\n person.name = f"{person.first_name} {person.last_name}"\n person.save()\n\n\nclass Migration(migrations.Migration):\n dependencies = [\n ("yourappname", "0001_initial"),\n ]\n\n operations = [\n migrations.RunPython(combine_names),\n ]\nOnce that’s done, we can run python manage.py migrate as normal and the\ndata migration will run in place alongside other migrations.
You can pass a second callable to\nRunPython to run whatever logic you\nwant executed when migrating backwards. If this callable is omitted, migrating\nbackwards will raise an exception.
When writing a RunPython function that uses models from apps other than the\none in which the migration is located, the migration’s dependencies\nattribute should include the latest migration of each app that is involved,\notherwise you may get an error similar to: LookupError: No installed app\nwith label 'myappname' when you try to retrieve the model in the RunPython\nfunction using apps.get_model().
In the following example, we have a migration in app1 which needs to use\nmodels in app2. We aren’t concerned with the details of move_m1 other\nthan the fact it will need to access models from both apps. Therefore we’ve\nadded a dependency that specifies the last migration of app2:
class Migration(migrations.Migration):\n dependencies = [\n ("app1", "0001_initial"),\n # added dependency to enable using models from app2 in move_m1\n ("app2", "0004_foobar"),\n ]\n\n operations = [\n migrations.RunPython(move_m1),\n ]\nIf you’re interested in the more advanced migration operations, or want\nto be able to write your own, see the migration operations reference and the “how-to” on writing migrations.
\nYou are encouraged to make migrations freely and not worry about how many you\nhave; the migration code is optimized to deal with hundreds at a time without\nmuch slowdown. However, eventually you will want to move back from having\nseveral hundred migrations to just a few, and that’s where squashing comes in.
\nSquashing is the act of reducing an existing set of many migrations down to\none (or sometimes a few) migrations which still represent the same changes.
\nDjango does this by taking all of your existing migrations, extracting their\nOperations and putting them all in sequence, and then running an optimizer\nover them to try and reduce the length of the list - for example, it knows\nthat CreateModel and\nDeleteModel cancel each other out,\nand it knows that AddField can be\nrolled into CreateModel.
Once the operation sequence has been reduced as much as possible - the amount\npossible depends on how closely intertwined your models are and if you have\nany RunSQL\nor RunPython operations (which can’t\nbe optimized through unless they are marked as elidable) - Django will then\nwrite it back out into a new set of migration files.
These files are marked to say they replace the previously-squashed migrations,\nso they can coexist with the old migration files, and Django will intelligently\nswitch between them depending where you are in the history. If you’re still\npart-way through the set of migrations that you squashed, it will keep using\nthem until it hits the end and then switch to the squashed history, while new\ninstalls will use the new squashed migration and skip all the old ones.
\nThis enables you to squash and not mess up systems currently in production\nthat aren’t fully up-to-date yet. The recommended process is to squash, keeping\nthe old files, commit and release, wait until all systems are upgraded with\nthe new release (or if you’re a third-party project, ensure your users upgrade\nreleases in order without skipping any), and then remove the old files, commit\nand do a second release.
\nThe command that backs all this is squashmigrations - pass it the\napp label and migration name you want to squash up to, and it’ll get to work:
$ ./manage.py squashmigrations myapp 0004\nWill squash the following migrations:\n - 0001_initial\n - 0002_some_change\n - 0003_another_change\n - 0004_undo_something\nDo you wish to proceed? [y/N] y\nOptimizing...\n Optimized from 12 operations to 7 operations.\nCreated new squashed migration /home/andrew/Programs/DjangoTest/test/migrations/0001_squashed_0004_undo_something.py\n You should commit this migration but leave the old ones in place;\n the new migration will be used for new installs. Once you are sure\n all instances of the codebase have applied the migrations you squashed,\n you can delete them.\nUse the squashmigrations --squashed-name option if you want to set\nthe name of the squashed migration rather than use an autogenerated one.
Note that model interdependencies in Django can get very complex, and squashing\nmay result in migrations that do not run; either mis-optimized (in which case\nyou can try again with --no-optimize, though you should also report an issue),\nor with a CircularDependencyError, in which case you can manually resolve it.
To manually resolve a CircularDependencyError, break out one of\nthe ForeignKeys in the circular dependency loop into a separate\nmigration, and move the dependency on the other app with it. If you’re unsure,\nsee how makemigrations deals with the problem when asked to create\nbrand new migrations from your models. In a future release of Django,\nsquashmigrations will be updated to attempt to resolve these errors\nitself.
Once you’ve squashed your migration, you should then commit it alongside the\nmigrations it replaces and distribute this change to all running instances\nof your application, making sure that they run migrate to store the change\nin their database.
You must then transition the squashed migration to a normal migration by:
\nDeleting all the migration files it replaces.
Updating all migrations that depend on the deleted migrations to depend on\nthe squashed migration instead.
Removing the replaces attribute in the Migration class of the\nsquashed migration (this is how Django tells that it is a squashed migration).
Migrations are Python files containing the old definitions of your models\n- thus, to write them, Django must take the current state of your models and\nserialize them out into a file.
\nWhile Django can serialize most things, there are some things that we just\ncan’t serialize out into a valid Python representation - there’s no Python\nstandard for how a value can be turned back into code (repr() only works\nfor basic values, and doesn’t specify import paths).
Django can serialize the following:
\nint, float, bool, str, bytes, None, NoneType
list, set, tuple, dict, range.
datetime.date, datetime.time, and datetime.datetime instances\n(include those that are timezone-aware)
decimal.Decimal instances
enum.Enum and enum.Flag instances
uuid.UUID instances
functools.partial() and functools.partialmethod instances\nwhich have serializable func, args, and keywords values.
Pure and concrete path objects from pathlib. Concrete paths are\nconverted to their pure path equivalent, e.g. pathlib.PosixPath to\npathlib.PurePosixPath.
os.PathLike instances, e.g. os.DirEntry, which are\nconverted to str or bytes using os.fspath().
LazyObject instances which wrap a serializable value.
Enumeration types (e.g. TextChoices or IntegerChoices) instances.
Any Django field
Any function or method reference (e.g. datetime.datetime.today) (must be\nin module’s top-level scope)
Functions may be decorated if wrapped properly, i.e. using\nfunctools.wraps()
The functools.cache() and functools.lru_cache() decorators are\nexplicitly supported
Unbound methods used from within the class body
Any class reference (must be in module’s top-level scope)
Anything with a custom deconstruct() method (see below)
Django cannot serialize:
\nNested classes
Arbitrary class instances (e.g. MyClass(4.3, 5.7))
Lambdas
You can serialize other types by writing a custom serializer. For example, if\nDjango didn’t serialize Decimal by default, you could do\nthis:
from decimal import Decimal\n\nfrom django.db.migrations.serializer import BaseSerializer\nfrom django.db.migrations.writer import MigrationWriter\n\n\nclass DecimalSerializer(BaseSerializer):\n def serialize(self):\n return repr(self.value), {"from decimal import Decimal"}\n\n\nMigrationWriter.register_serializer(Decimal, DecimalSerializer)\nThe first argument of MigrationWriter.register_serializer() is a type or\niterable of types that should use the serializer.
The serialize() method of your serializer must return a string of how the\nvalue should appear in migrations and a set of any imports that are needed in\nthe migration.
deconstruct() methodLink to this heading#You can let Django serialize your own custom class instances by giving the class\na deconstruct() method. It takes no arguments, and should return a tuple\nof three things (path, args, kwargs):
path should be the Python path to the class, with the class name included\nas the last part (for example, myapp.custom_things.MyClass). If your\nclass is not available at the top level of a module it is not serializable.
args should be a list of positional arguments to pass to your class’\n__init__ method. Everything in this list should itself be serializable.
kwargs should be a dict of keyword arguments to pass to your class’\n__init__ method. Every value should itself be serializable.
Django will write out the value as an instantiation of your class with the\ngiven arguments, similar to the way it writes out references to Django fields.
\nTo prevent a new migration from being created each time\nmakemigrations is run, you should also add a __eq__() method to\nthe decorated class. This function will be called by Django’s migration\nframework to detect changes between states.
As long as all of the arguments to your class’ constructor are themselves\nserializable, you can use the @deconstructible class decorator from\ndjango.utils.deconstruct to add the deconstruct() method:
from django.utils.deconstruct import deconstructible\n\n\n@deconstructible\nclass MyCustomClass:\n def __init__(self, foo=1):\n self.foo = foo\n ...\n\n def __eq__(self, other):\n return self.foo == other.foo\nThe decorator adds logic to capture and preserve the arguments on their\nway into your constructor, and then returns those arguments exactly when\ndeconstruct() is called.
\nIf you are the maintainer of a third-party app with models, you may need to\nship migrations that support multiple Django versions. In this case, you should\nalways run makemigrations with the lowest Django version you wish\nto support.
The migrations system will maintain backwards-compatibility according to the\nsame policy as the rest of Django, so migration files generated on Django X.Y\nshould run unchanged on Django X.Y+1. The migrations system does not promise\nforwards-compatibility, however. New features may be added, and migration files\ngenerated with newer versions of Django may not work on older versions.
\n\n