What is the difference between syncdb and migrate? - python

I am going through django documentation. And here I have a situation. In one of the documentation, I am told to do
python manage.py migrate
And in the other
python manage.py syncdb
I can't do the first one(Error: no migrate command found.) but second works fine for me. Is this a version issue or I need to take care of something else.

The migrate command is new in the upcoming Django 1.7, which hasn't been released yet.
For earlier versions you can use syncdb, or the external app South.
When you're reading the documentation, use the Documentation version switcher to select the correct version.
For example, the current 1.6 Tutorial uses syncdb, but the dev tutorial (written for the upcoming 1.7) uses migrate.

The command migrate belongs to an application called south (http://south.aeracode.org/).
From the website:
This is South, intelligent schema and data migrations for ​Django projects.
Prior to Django==1.7 you had to install a third party application in order to perform database migrations.
Please see documentation at readthedocs

It depends what version of the documentation you are reading. migrate is the command from South which up until the latest (currently development, or dev) version of django was a separate app. It's finally getting integrated into Django (basically every django project uses it anyway as a matter of course, so it is well worth reading up on).
In the bottom right of the django documentation page there is a selector where you can switch between different versions of Django, so if you're looking for information for your project it is a good idea to change to the version of Django you're currently using.

Related

Migrate web2py project to a newer version

I got an extensive web2py project which is currently still running on web2py 2.0.9 .
I would like to migrate it to the newest version 2.14.6 to get the more extensive bootstrap options and more styling possibilities.
What would be the things I would most likely run into and what would be the best course of action?

NoMigrations error in Django

I am building an app called 'competencies'. I made changes to models, migrated the app locally, and everything worked. This is my eighth migration on the app.
I have deployed the app on heroku, so I committed changes and pushed to heroku. I can see that the changes went through, because the new migrations appear in the heroku files. When I log in to heroku and try to migrate the competencies app, I get the following error:
NoMigrations: Application '<module 'django.contrib.admin' from '/app/.heroku/python/lib/python2.7/site-packages/django/contrib/admin/__init__.py'>' has no migrations.
I have searched for this error, and I have not found anything meaningful. Can anyone suggest what I am doing wrong, or how to address the issue?
django.contrib.admin should not have migrations. Contrib packages are not south managed.
If you EVER ran python manage.py schemamigration django.contrib.auth --XXX on your local it would create the migrations folder in your local copy's install of the venv's django. However, this will never get transferred to heroku.
test something for me. create a new copy of your site on your local machine
new DB
new virtualenv
new folder w/ new clone of repo
try to run python manage.py migrate if you get the same error its b/c you broke your virtualenv with south.
Something else you could try IF your database models have not changed a bunch since the last working copy:
roll your models back to the last working configuration
delete EVERY app's migrations folder
truncate south_migrations table
run python manage.py schemamigration --initial X for each of your apps.
push and migrate --fake
redo your model changes
create migrations for the model changes
push and migrate regularly
I recently encountered this error after dumping a live database to a dev box for testing data migrations.
One of the dependencies was throwing this error (specifically taggit). I think that I have a different version of taggit on the dev box which does not have migrations, but the database I dumped had two migrations for taggit in south_migrationhistory.
I deleted the entries in south_migrationhistory for the problem app erroneously claiming NoMigrations and that solved my problem. Everything's running again.
Apart from many answers posted above, south.exceptions.NoMigrations is often exception after 2014 (Django 1.7) because of changed migrations directory. The directory is default for Django built in migrations.
For south migration, the directory is south_migrations. South>=1.0 can recognize this and automatically detect migrations. See details here on Django docs
In this case, update South:
pip install -U South
Or you can also specify migration directory on settings file (for every app installed).
I found an odd edge case, involving Kombu.
I'm maintaining a legacy Django 1.5 project on Ubuntu 14.04, and I previously had this setting to get Kombu to play nicely:
SOUTH_MIGRATION_MODULES = {
'kombu_transport_django': 'kombu.transport.django.south_migrations',
}
However, after I upgraded to Ubuntu 16, there were some minor tweaks in the Python stdlib that again broke Kombu. Upgrading Kombu was the only immediate solution, but that gave me another Kombu error similar to what OP found:
NoMigrations: Application '<module 'kombu.transport.django' from '/myproject/.env/local/lib/python2.7/site-packages/kombu/transport/django/__init__.pyc'>' has no migrations.
This error message is nearly worthless, but I eventually realized the problem was my SOUTH_MIGRATION_MODULES setting. It turns out, the old kombu.transport.django.south_migrations was removed, and South trying to import this missing migration directory is what was causing the error. The fix was to remove that line.
Try pip install --upgrade django
The NoMigrations error often shows up if you downgrade your Django version.
In my case, I had installed a package which automatically uninstalled my current Django version and installed a downgraded it.
Installing the updated version was a quick fix.
Also, you may want to check in your INSTALLED_APPS if you have included all of your apps including the 'django.contrib.auth' and 'django.contrib.admin'

Django manage.py syncdb doing nothing when used with sqlite3

I'm not sure if this is an issue specific to sqlite databases but after adding some properties I executed syncdb successfully but still the the columns were not added to the database and when I try the access the model in admin I get no such column error.
Why is this happening and how do I overcome this issue?
Details: Django 1.3, Python 2.6, OSX 10.6, PyCharm.
sync db doesn't make integrate schema changes once the tables are created. You have to delete the database manually and do syncdb again. See the boxed information in this link
http://docs.djangoproject.com/en/dev/ref/django-admin/#syncdb
As always, syncdb does not migrate the existing schema.
I think one can find solution here: A nice blog to start with Django:
Getting Started with Django REST Framework (DRF) and AngularJS :
http://engineroom.trackmaven.com/blog/getting-started-drf-angularjs-part-1/

django syncdb and an updated model

I have recently updated my model, added a BooleanField to it however when I do python manage.py syncdb, it doesn't add the new field to the database for the model. How can I fix this ?
From Django 1.7 onwards
Django has built in support for migrations - take a look at the documentation.
For Django 1.6 and earlier
Django doesn't support migrations out of the box. There is a pluggable app for Django that does exactly that though, and it works great. It's called South.
Django currently does not do this automatically. Your options are:
Drop the table from the database, then recreate it in new form using syncdb.
Print out SQL for the database using python manage.py sql (appname), find the added line for the field and add it manually using alter table SQL command. (This will also allow you to choose values of the field for your current records.)
Use South (per Dominic's answer).
Follow these steps:
Export your data to a fixture using the dumpdata management command
Drop the table
Run syncdb
Reload your data from the fixture using the loaddata management command
As suggested in top answer, I tried using South, and after an hour of frustration with obscure migration errors decided to go with Django Evolution instead.
I think it's easier to get started with than South, and it worked perfectly the first time I typed ./manage.py evolve --hint --execute, so I'm happy with it.
Havent used django in a while, but i seem to remember that syncdb does perform alter commands on db tables. you have to drop the table then run again and it will create again.
edit: sorry does NOT perform alter.
In django 1.6
At first we have run - python manage.py sql <app name>
Then we have to run - python manage.py syncdb
If you run Django with Apache and MySQL, restart apache after making migration with makemigrations.

update django database to reflect changes in existing models

I've already defined a model and created its associated database via manager.py syncdb. Now that I've added some fields to the model, I tried syncdb again, but no output appears. Upon trying to access these new fields from my templates, I get a "No Such Column" exception, leading me to believe that syncdb didn't actually update the database. What's the right command here?
As of Django 1.7+, built-in migrations support, allows for database schema migrations that preserve data. That's probably a better approach than the solution below.
Another option, not requiring additional apps, is to use the built in manage.py functions to export your data, clear the database and restore the exported data.
The methods below will update the database tables for your app, but will completely destroy any data that existed in those tables. If the changes you made to your app model do not break your old schema (for instance, you added a new, optional field) you can simply dump the data before and reload it afterwards, like so:
Django 1.4.15 and earlier
python manage.py dumpdata <your_app> > temp_data.json
python manage.py reset <your_app>
python manage.py loaddata temp_data.json
Django 1.5 and newer
python manage.py dumpdata <your_app> > temp_data.json
python manage.py sqlclear <your_app> | python manage.py dbshell
python manage.py syncdb
python manage.py loaddata temp_data.json
(The reset command was deprecated and then removed in Django 1.5)
If your changes break your old schema this won't work - in which case tools like South or Django Evolution are great.
As of Django 1.7, you can now do this with native migrations. Just run
python manage.py makemigrations <your app name>
python manage.py migrate
Seems like what you need is a migration system. South is really nice, working great, has some automation tools to ease your workflow. And has a great tutorial.
note: syncdb can't update your existing tables. Sometimes it's impossible to decide what to do automagicly - that's why south scripts are this great.
Django's syncdb doesn't alter existing tables in the database so you have to do it manually. The way I always do it is:
Change the model class first.
Then run: manage.py sql myapp.
Look at the sql it prints out and see how it represented the change you are going to make.
Make the change manually using your database manager.
Check to see if everything worked correctly using the admin site.
If you are using sqllite a good manager is the firefox plugin: link
Another tool would be django evolution. No table dropping needed in most cases.
django evolution
Just install it as any other django app and run:
python manage.py evolve --hint --execute
deseb is a great tool for that.
Having it installed, you can write ./manage.py sqlevolve and it'll generate sql commands necessary to keep the database structure in sync with your models.
You need to drop your tables before you can recreate them with syncdb.
If you want to preserve your existing data, then you need to unload your database,
drop your tables, run syncdb to build a new database, then reload your old data into your new tables.
There are tools that help with this. However, in many cases, it's just as easy to do it manually.
For versions 1.4.1 and above users the command has changed to
python manage.py flush
Please read the official document before using it as it will delete all your data.

Categories