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.
Related
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.
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.
I have come across an interesting problem. I first created a model. And syncdb'ed it. Later on I changed the model by adding one models.DateField() and a models.DateTime(). Than I re syncdb'ed it... However the when I checked the database the rows were not added. Is this normal behaviour or did I do something wrong? Later on I deleted all tables and syncdb'ed and got all rows with no problems.
No, the docs are quite explicit that it does not alter existing tables.
Use something like South.
Django itself doesn't support db migrations. You will need to look into South for this.
This is a good place to start.
In every generated migration files by South manage.py schemamigration, there usually will be a subclass of the south.v2.SchemaMigration. The class would contain forwards() and backwards() methods and also models attribute. How does South use the models attribute?
This is called ORM freezing.
We also use a human-readable format that’s easy to change; since South relies on the frozen models not only for reacreating the ORM but also for detecting changes, it’s really useful to be able to edit them now and again (and also serves as a valuable debugging tool if you attach failing migrations to a ticket).
http://south.aeracode.org/docs/ormfreezing.html
How does Django handle changes to my Model? Or, what help does it offer me to do this?
I am thinking of a situation where I have already have published data to my DB which I don't want to lose, but I need to make changes to my data model - for example, adding extra fields to a particular class, changing the types of fields, etc. My understanding is that syncdb won't ever alter tables that already exist in the DB.
For example, let's say I have the following model:
class Person(models.Model):
name = models.CharField(max_length=200)
phone_number=models.CharField(max_length=200)
hair_colour=CharField(max_length=50)
Things I might want to do to Person off the top of my head:
I wish to add an 'age' field.
I realise I want to use IntegerField instead of CharField for phone_number (whether this is a good idea or not, is out of scope...) - assuming it's possible.
I realise that I no longer wish to define hair_colour 'inline' within Person, because several people share the same hair colour - I wish instead to change this to be a foreign key to some other model.
Whilst I can imagine some of these are tough/impossible for the framework to 'guess' exactly what needs to be done to my data if all I do is update the models.py, I can imagine that there might still be some tooling to help enable it - does it exist?
In particular I imagine there must be some good patterns for option 1.
I'm very new to Django and have no experience with any other ORM-type stuff, which I think this is - I've always been a bit suspicious of ORMs, mainly for the reasons above :)
Django itself will not attempt to modify an already created database table. What you are trying to do is typically called "Migration" and there are a couple of different Database Migration tools available for Django.
South
Schema Migrations
Data Migrations
Backwards Migrations
Nash Vegas
Schema Migrations
Data Migrations
Django Evolution
Schema Migrations
Data Migrations (Unknown)
Backwards Migrations (Unknown)
Of the three South is probably the most widely used but they each have different ways of dealing with migrations. You can see more details on the comparison on Django Packages.
Much of what you're asking about can be done with the django project South. You add it as an INSTALLED_APP. Create a baseline, then as your model changes it creates SQL statements to convert your tables and the rows with-in the tables to the new model format.