16👍
As soon as I am about push a commit that other people need to use, I create a migration so they can still have a working copy.
If you are working alone(and not worrying about deployment), this is not an issue and you can wait until the last possible moment to create a migration.
Once you begin working with others, it makes life easier to quickly make migrations so it becomes a workflow habit and everyone is on the same database page.
Also, syncdb is not an option if you are simply modifying a field. It gets incredibly annoying to have to blow away a table just for adding, deleting or modifying fields.
If I have a bunch of schema migrations that I added, sometimes I will combine them(rollback and delete them and create a new jumbo migration) into a single migration. But normally, the number of migrations doesn’t bother me because they don’t cost me anything really.
4👍
I’ve found South to be just as useful during development as afterwards, precisely because the table fields are changing so often. It’s pretty annoying to have to drop a table and re-create it with syncdb just to add one field, especially if you have any test data at all. (You could also just modify the table directly in your DBMS, but then you have to be careful to use the same field type that Django is expecting, set the attributes like ON DELETE appropriately, etc.). Plus if anyone else is working on the project, you have to make sure to tell them to make exactly the same changes to their copy of the database. South makes it much simpler, IMO.
That being said, it might be cool if South had an option to delete all previous migrations, so you could start with a clean slate when you’re wrapping up the initial dev and starting to add real data. But ultimately those dozen or so extra migration files aren’t really costing you anything.
- Allow a task execution if it's not already scheduled using celery
- How to set value of a ManyToMany field in Django?
- Geodjango using mysql
- Django REST Framework Swagger 2.0
- Django aggregation: sum then average
2👍
I don’t use South during the initial development. I just have a script which creates fixtures for each app, so when the schema changes, I dump the old testing data, edit the schema, update the testing data so that it will work with the new schema, then restore the data.
0👍
It definitely is possible to use south from a certain stage on and do an initial migration. SOuth docs here: http://south.aeracode.org/docs/tutorial/part1.html#converting-existing-apps
I do use south during development, as i often have data that i use to test the UI or such things. South is also very helpful in keeping your database consistent if you do not start with a complete new database after every model change. Therefor i agree with meder too, it would be great if Django would have that schema migration, on the other hand it doesn’t matter that much as south is very easy to implement.
- How to render a Django form with RadioSelect without getting a checked radiobutton by default?
- Django template {%for%} tag add li every 4th element
- Django-Rest-Framework serializer class meta
- Use slugify in template
0👍
Good news – as of 2nd September 2014 migrations are now part of core Django, release 1.7.
https://docs.djangoproject.com/en/dev/releases/1.7/
I was just about to install South, and now I don’t have to. Hope this gives a useful heads-up to other users in the same situation.
- Django queryset filter GT, LT, GTE, LTE returns full object list
- 'QuerySet' object has no attribute ERROR, trying to get related data on ManyToMany fields
- Django+Nginx+uWSGI = 504 Gateway Time-out