Another update:
-- The actual problem was the automatically generated migrations from the makemigrations command removed the database fields before removing the constraints on those fields (leading to a FieldDoesNotExist error when trying to drop the constraint). The solution was just to move the RemoveField operation below the AlterUniqueTogether operation in the migration file. (Also, it turns out that removing the "_id" suffix didn't matter after all).
Thanks again for the help, everyone!
On Tuesday, October 20, 2015 at 10:18:02 PM UTC-7, Daniel Chen wrote:
On Tuesday, October 20, 2015 at 10:18:02 PM UTC-7, Daniel Chen wrote:
Hi all,Thanks for all the help! Sorry for the incredibly slow response, but I just wanted to give an update:The problem was that I was trying to remove a foreign key (let's call that foreign key "book", referencing a "book" table). I had to manually go into the migration and add '_id' (e.g., "book_id") in every reference to that model (odd that you need to manually update the migrations, but whatever). Afterwards, I was able to successfully dump the DML - which looked more or less correct.However, the next problem was that I had unique_together constraints on that foreign key and another existing key (e.g., unique_together("book_id", "author_id")). I got the corresponding error message: "ValueError: Found wrong number (0) of constraints for main_tablename(book_id, author_id)", so I still wasn't able to complete the migration.I worked around this by not dropping that column ("book_id" is still in the table), and the migration finally worked. However, I'd love to get rid of that column once and for all. So, if anyone knows a solution, please let me know!Dan
On Friday, October 2, 2015 at 11:26:50 PM UTC-7, James Schneider wrote:@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 iNo. 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.Whoops, looks like part of my response got wrapped around Mike's by accident. Here's what it was supposed to say:"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 issue. 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."-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+unsubscribe@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/886186b5-737e-447e-b53b-86185316e3cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment