#27142: makemigrations fails on special database connections
---------------------------------+------------------------------------
     Reporter:  gerricom         |                    Owner:  nobody
         Type:  Bug              |                   Status:  new
    Component:  Migrations       |                  Version:  1.10
     Severity:  Release blocker  |               Resolution:
     Keywords:                   |             Triage Stage:  Accepted
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+------------------------------------

Comment (by shaib):

 The issue is that `makemigrations` does not have a target database, while
 `migrate` does. So, in order to check for consistent history,
 `makemigrations` checks all databases. After this didn't work, the fix was
 "well, all databases which look like they have migrations", and this still
 fails.

 I see two possible solutions:

 1. Use the DB routing mechanism to find the list of databases which can
 actually be migrated (for the relevant app), and only check consistency in
 these databases. Then, users with databases which shouldn't be migrated
 will have an obvious way to protect them.

 2. Claim that "makemigrations" shouldn't actually touch the database --
 essentially, that it's an operation whose only arguments are the
 migrations and models -- and accept Tim's suggestion.

 It's been a while since I looked at the migration generator, but I suspect
 that it does ask the database some questions about features etc, which
 would somewhat violate route 2.

 I think `makemigrations` is a place where we should check consistency,
 because one of the two possible reasons for inconsistent history is
 erroneous editing of migration files; creating the next migration on top
 of an error is something we should prevent if we can, IMO.

 I also think just removing the check because of "too many problems", with
 no principled reasoning behind it, is not a good option, but I won't argue
 too hard for that; practicality beats purity.

--
Ticket URL: <https://code.djangoproject.com/ticket/27142#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1c889ed851d356bacf61fd39abe09fd9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to