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:
>
> 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 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.
>>>
>>
>> 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 [email protected].
To post to this group, send email to [email protected].
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.
