On Fri, Oct 2, 2015 at 3:37 PM, Daniel Chen <dan...@a16z.com> wrote: > @Mike: I'm using Python 2.7.10 and Django 1.7. I'm not sure the ticket > applies, but I appreciate the link! > > @James: Sorry, I misspoke! [field] actually corresponds to a old field in > state X. Before adding the new fields in state Y, the migration is trying > to remove some old fields in state X but isn't finding them. I think this > means that I'm unable to re-run that migration since it's looking for state > X fields to remove, but can't find them (the model is already in state Y). > My confusion is in the fact that the model state wouldn't roll back to > state X after the first failed transaction (like the DB did). >
That makes even less sense than your original issue. Are you sure that migration X was applied properly? What versions of migrations are stored in your django_migrations table? Is the latest migration listed in there for your app? You should be able to find it with a raw SQL statement, something like "select * from django_migrations where app = '<app_name>';". Does [field] currently exist in your database so that it can be removed? If not, you've had issues with migrations beyond this particular i No. The model is all your own work. Anything you write stays written. The migration system tries to implement your work. If it fails, it will roll the database back to its previous state. It does nothing to your work. You need to take note of the failure, decide how to fix your work and try again. ssue. Were any migration files removed? Does the database match migration X? Even better, can you also post the full traceback that you receive during the failed migrations? That might lead to more clues. > > This would be analogous to my writing you a check that will bounce. Once > the check bounces, both your personal wealth and your bank statement should > be back to what they were originally. But in this particular case, it looks > like your personal wealth is stuck in a state that assumes the check has > been cashed and your account has been credited, but your bank account > disagrees :) > > Oh well, worth a shot. :-D > By the way, I talk about model state under the assumption that the Django > ORM somehow internally keeps track of the models - I'm not sure exactly how > it does this or if it does this at all. If you could tell me more about > this, that'd be much appreciated! > The ORM will use whatever model definitions contained within the models.py, regardless of database state. It has no idea whether or not the equivalent fields exist in the database (until an exception is thrown when the DB returns an error accessing a missing field, etc.). Migrations are a process completely outside and separate of Django running as an application via runserver or a WSGI process. Migration files are the only files that would keep versions of your models, and are not consulted at any time except during migrations. So if you change anything in models.py, you should create a new migration and apply it before doing any further development. -James -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUcG6aKH-Mfmoav62ThR%3D6yL5J2JJjE2DArE2mh0Uumhw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
