I just installed django-mptt using PIP (meaning I have 0.5.5), changed an existing model ("Comment") to subclass from MPTTModel, and tried to do a schema migration with South, but South gave me the following error message:
The field 'Comment.lft' does not have a default specified, yet is NOT NULL. Since you are adding this field, you MUST specify a default value to use for existing rows. Would you like to:
Quit now, and add a default to the field in models.py
Specify a one-off value to use for existing columns now
Please select a choice:
In this thread, it looks like the developers suggest telling South to use "0", but then someone else suggests doing so would create another issue. If anyone could shed light on what I may be doing wrong, or how I should respond, I would be very grateful.
As Victor suggested, setting "None" as the default when prompted was the proper course of action. However, it may also be necessary to use the rebuild() method on the model after the migration. I also posted to the django-mptt-dev Google Group, and the package author, Craig de Stigter replied with the following:
If your migration imports the actual models (not the south ORM ones) and does a YourModel.objects.rebuild() at the end of the migration, it should migrate correctly. The actual value you use for the mptt fields in the meantime is irrelevant as the rebuild() will override it.
I asked him to clarify whether he was saying I could specify "None" when asked by South to set a default value, and then go to a shell and use rebuild(), and he said yes.
In any event, it seems to have worked for me.
Related
I'm trying to remove a concrete parent model and copy some of its fields directly onto the child. I have performed a similar process several times before using South (the same parent model on other children), but since upgrading to Django 1.7, it's just not playing the game. Django gives the following error during the migrate process:
FieldError: Local field <field_name> in class <child_model> clashes with field of similar name from base class <parent_model>
At the point that both makemigrations and migrate are run and this error occurs, the parent model no longer appears in the code as the parent of the class, yet the migration still complains.
A similar question has been asked here before and the accepted solution involves creating a new model, copying data to it, replacing the existing model, and copying the data back. Unfortunately, this approach will not work in my case. It is an established model with numerous foreign keys pointing back to it, which would be lost if the original records were removed.
The (simplified) approach I used under South was:
Remove the model as the parent and add the new fields to the child
Add an explicit primary key field with the same name as the old auto *_ptr_id field
Run schemamigration and edit the file to:
Remove South's attempt to remove and recreate the *_ptr field
Add some custom logic to remove the ForeignKey-ness of the *_ptr_id field and add PrimaryKey-ness
Use a datamigration to grab the values off the old parent and add them to the new fields on the child
This is the approach I was hoping would be reasonably easily adapted to native Django migrations, and I got (with some tweaking) the *_ptr_id field replacement logic going. But Django won't let me add the new fields. I have tried the following:
Removing the parent model and performing the custom *_ptr_id replacement, migrating, and adding the fields as a second migration.
Removing the parent model and not editing the file to manually mess with *_ptr_id, but leaving Django's remove/add operations and migrating with --fake.
In both scenarios, a later migration that adds new fields with the same name as those on the old parent causes the above error. Django refuses to acknowledge that the old parent model is no longer a parent of the class.
Has anyone else had this problem and been able to work around it?
Edit:
This appears to be caused by the bases argument of the CreateModel schema operation class listing the parent model, and the lack of a matching operation to update the list. The documentation for CreateModel lists this argument as optional, but are there any side-effects to manually changing this value in a previously applied migration?
After hitting this same problem in Django 1.11, I followed the edited advice and found the initial 'CreateModel' call in my migrations files. Commenting out the bases=('{appname}.{modelname}',), line and explicitly setting my model's primary key to be 'id' then re-running makemigrations and migrate fixed the issue for me.
I'm not sure if the primary key change is relevant to the solution, I'm just laying out variables.
Another option for people less invested in their model name (and data): rename it when you remove the parent. Note that while this worked for me, switching back to the original model name in another migration hit this same "once a child, always a child" error, so you'll still need to edit the 'bases=' line in your migrations.
Thanks oogles and Community!
I want to know if any one could give a complete list of things which need to be done when we want to remove a model from Django. I know that a similar question was asked. But it seems to be several years ago, when people were still using South to deal with Database. So I expect an answer for the recent version of Django.
I conclude what I know as follows:
Delete the codes for model from model.py
Make sure that no other file imports this model or uses them
(admin.py, views.py, etc)
Run makemigrations and migrate commands
Since Django doesn't clean database for you, you delete the table of
this model manually from you database
Also note that there is a table called ContentTypes, which keeps
records about the info our your every model. So you need to delete
the record for this model manually (But I don't know how to do it
exactly. Would any one give some explanation?)
These are all the things I know. Is there anything wrong? And did I forget anything? Maybe I'm over-cautious, but I'd like to keep the database clean.
Thanks a lot!
In Django 1.7, this is actually much simpler than you think. Let's say you have an app, books, with two models: Book and BookReview. You want to remove the Book model.
Remove all references to the Book model in your code. For example, remove the ForeignKey('books.Book') field on the BookReview model. There is no need to make a separate migration for this change.
Remove the code for the Book model from books/models.py. Now, create a migration (manage.py makemigrations). If you look at the migration that is generated, it should include a migrations.DeleteModel operation.
Run the auto-generated migration (manage.py migrate), and you should be asked about the relevant ContentType objects that are no longer needed:
Running migrations:
Applying books.0002_auto_20150314_0604... OK
The following content types are stale and need to be deleted:
books | book
Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
You probably do want to delete the content types. If you don't want to be asked for input, you can use manage.py migrate --noinput.
The DeleteModel operation in this migration will drop the books_book table in your database, so you don't have to worry about manually cleaning up at all.
Back in previous versions of Django, we all used South to do migrations, and because it wasn't as smart as we might have liked, we sometimes needed to tell it to explicitly ignore some fields because such fields were too complicated for it to handle. We did this with add_ignored_fields and everything pretty much worked.
In our case, we have a "field" on our model that's a subclass of CharField that actually attaches two additional fields to the model via the contribute_to_class method. It's kind of a weird process, but it makes sense for our use case and worked just fine until we upgraded to Django 1.7.
However, with the new migrations system, our use of add_ignored_fields() no longer works and our unit tests are exploding as it tries to create a test database table with these fields. Specifically it says:
django.db.utils.OperationalError: duplicate column name: our_column_name
In this case our_column_name is one of the fields this special CharField subclass creates.
In a perfect world, we could have the migration code handle these fields properly, but I'd settle for the 1.7 version of add_ignored_fields() if it exists.
I should also point out that we've found the explanation for deconstruct in the Django documentation, but I'm afraid that it doesn't make any sense to me. I can't figure out if it applies to this situation or not.
We've discovered this Django ticket that pretty much states that this is a design pattern that the devs aren't supporting, so we're just going to have to rewrite the model to explicitly create the other fields on the model and then reference said fields from the "parent" field a la ImageField.
I'd like to replace an existing ForeignKey pointing at my User model with one pointing at a profile model.
The change in the model is:
created_by=models.ForeignKey(settings.AUTH_USER_MODULE)
To:
created_by=models.ForeignKey(settings.PROFILE_MODEL)
The auto-generated migration looks like (with constants subbed in):
migrations.AlterField(
model_name=MODEL,
name='created_by',
field=models.ForeignKey(to=settings.PROFILE_MODEL),
preserve_default=True,
),
I also have ManyToManyFields to deal with as well. What I have in my head is I'd like a function to run on each MODEL object to resolve the user object to the profile object. How would I go about doing this?
The relationship between user and profile is (and vice versa):
User.profile = Profile
Edit: Forgot to mention, if the auto-generated migration is run you get the following error:
ValueError: Lookup failed for model referenced by field
APP1.MODEL.created_by: APP2.PROFILE_MODEL
As I understand now you want to migrate only our app without expecting anything to be changed to the global auth User model. Then it's easy. Migrations work nice with symbolic settings names.
I tried it with Django 1.7. It is possible to switch between settings.AUTH_USER_MODEL and settings.PROFILE_MODEL back and forth without any problem. A migration can be created and applied after every change. The tested model had also a ManyToManyField and mutual relationships between User and Profile.
I see you have APP1 and APP2. Maybe you make migrations for both and they are circular dependent so that a part of other application migration should be applied before the current one migration can be completely applied and vice versa. It can be simplified by spliting a change to more smaller and making automatic migrations after every change so that they are less dependent. A OneToOneField is better than two mutual foreign keys and its reverse relation is even so useful. A foreign key can be changed temporarily to IntegerField(null=True) in the worst case in order to simplify data migration. It is really viable more or less nice.
The question looked nice initially, but the problem should be better specified to be reproducible.
Edited by removing the original text after reading information in comments:
I'm using South for migrations. I can't seem to work out if South can also be used to amend the models themselves. Upon returning to a previous model state, am I to manually alter the code?
Thanks
South does not modify your models.py. It only alters the database. It is generally used in conjunction with version control software (such as git) that would allow you to revert your models.py to match the south migration.
am I to manually alter the code?
Yes. South altering models code seems for me not like a good idea. Only you know what where exact code changes because of your migration.
And for me, I performed backwards migration couple times and in most cases didn't wanted the model to change to previous state.