Menu
We're applying Black code style to a django project.
In all the tutorials / examples I find (such as in django cookiecutter and this blog), I keep seeing django's migrations files excluded from the linter.
But to my mind, these are still python files. Sure, django may not autogenerate them to meet the Black spec. But it's not like developers always write their code to meet Black spec... that's what linting is for!
Why would migration files be considered different to any other python files?!
NB I'm aware of the possibility of changing an already-applied migration if you've got pre-existing migrations - this requires care on first application (as does first application to the rest of the codebase, frankly) but surely isn't a reason not to do it?
EDIT - @torxed asked for an example of a django migration file
I'm not sure how helpful this'll be tbh, but a typical django migration file might look like this (in this case adding a char field to a table):
# Generated by Django 2.2.3 on 2019-10-28 09:45
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('api', '0009_figures_notes_tables'),
]
operations = [
migrations.AlterField(
model_name='project',
name='processed_kmz_sha',
field=models.CharField(max_length=255),
),
]
564
Third, migrations should be included in code review. They are significant changes to your production system, and there are lots of things that can go wrong with them. So in short, if you care about your production data, please check your migrations into version control.
Migrations are Django's way of propagating changes you make to your models (adding a field, deleting a model, etc.) into your database schema. They're designed to be mostly automatic, but you'll need to know when to make migrations, when to run them, and the common problems you might run into.
Migrations are Python files containing the old definitions of your models - thus, to write them, Django must take the current state of your models and serialize them out into a file.
Show activity on this post. This way a new migration file will be created. Set your column details there, run the migrations using php artisan migrate and that's all. You'll have this new column in your users table without losing previously stored data.
For example, you can exclude all .mp3 files on the computer, or you can exclude all files from C:\UserData. Create a Config.xml File: You can create and modify a Config.xml file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications.
In addition, creating and modifying a Config.xml file is the only way to exclude the operating-system settings that are migrated to computers running Windows. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax.
Because change based migrations work by outlining the operations required from a known database state to the desired one, an unbroken chain of migration files is necessary from the initial starting point.
All migration systems rely on understanding the current state of the database to correctly modify the existing structures. If the actual state diverges from the assumed state, the migrations may fail or may change the database in undesirable ways. Another potential problem with migrations is that they are often very tool specific.
I bit the bullet and applied Black to my migrations files, progressively across half a dozen django projects.
No problems at all, everything deployed in production for months now.
So the answer is: No reason at all why not to do this, and I think migrations files should be included, so that reading them is a consistent experience with the rest of the project.
168
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
