-1

I'm just beginning my journey with Django framework and I read that Django developers have made using migrations mandatory beginning from version 2.0. I might be old school but I like my database separate from my code. I have always kept my database separate from my code models. I think that the migrations won't scale with the engineering team size.

So my question is 2 fold.

  1. Can you not use Django 2.0 without the migrations as I don't think it will scale well and won't fit the CI/CD pipeline?
  2. If we can't avoid the db migrations then how can we integrate them in a robust CI/CD pipeline where a model can be changed by different developers from different teams.
dicemaster
  • 1,203
  • 10
  • 22
  • I'm not sure why you think migrations are a problem with a large team. Sure, there's some pains when working with multiple branches and [this post](https://cheesecakelabs.com/blog/really-annoys-django-migrations/) might help. Also it helps to squash migrations often (have someone do that every now and then). But if you use git-flow and have someone check the migration merges (you'll often have dependency conflicts, where `makemigrations merge` will be required), I don't see the big issue. – dirkgroten Mar 29 '19 at 17:50

2 Answers2

2

Yes, you can. You can create your tables manually and set Django to not manage your tables.

After your Django project is configured, just run on your terminal python manage.py inspectdb > models.py, and django will pick the models on the configured database. This is particularly good if your project will use a already existing or legacy database

Then, you can tell django to not manage your tables on the meta options of the model:

class MyModel(models.Model):
    # your fields here

    class Meta:
       managed = False

See the docs here

But, unless you have a very good way to keep track of your table changes, I must say this is a mistake. Django migrations help you to keep track on your models changes along the way. It is really helpful if you need to rollback or understand your database history.

Stargazer
  • 1,442
  • 12
  • 19
  • 1
    Using `managed = False` makes it very difficult for your developers to actually run unit tests, because they have to create the tables in all the `setUp` methods. It might be possible to set a [database router](https://docs.djangoproject.com/en/2.1/topics/db/multi-db/#database-routers) for the default database with `allow_migrate()` returning `False` but I'm not sure. – dirkgroten Mar 29 '19 at 17:39
  • Very good point, @dirkgroten. I solved that changing `managed = True` on my models Meta on the `setUp()`. It was a pain, though. – Stargazer Mar 29 '19 at 17:44
0

  1. Migrations are not mandatory, it's not clear what you think has changed in 2.0 to make them so.

  2. Migrations are intended for large teams. If you avoid them, you'll make things much much harder for yourself and your fellow team members.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895