I have a Django application initially created for version 1.6 and I've just finished the upgrade for the last version. All the models has managed = False and prior none of them was managed by south and now I want to start using Django migrations for 1.7 version.
Which would be the best and seamless way to do it? I'm afraid that just changing managed = True in all models and run manage.py makemigrations will make a mess in both migrations files and database.
Thanks
EDIT
As was suggested I ran manage.py makemigrations. It created the script 0001_initial with some model definitions but not for all the objects in models package. It creates 11 tables but I have 19 tables. All models has managed = True and I don't have any database router.
Most depends by the code
The project does not have migrations at all
./manage.py makemigrations
./manage.py migrate
The project has South migrations:
you can:
move the south migrations in south_migrations
or
totally remove the south migrations
and
./manage.py makemigrations
./manage.py migrate
if you go for option 1 you have to remember to keep uptodate your migrations with both systems (south and django). This is useful only if you want to keep django <1.7 compatibility
You have a pluggable application
This is the most complex situataion as you must preserve the south compatibility and you have to manage different version of south. Here the how to:
move the south migrations in south_migrations
run ./manage.py makemigrations
to prevent South to load the wrong migratins put the following code into migration.__init__.py
```
"""
Django migrations
This package does not contain South migrations. South migrations can be found
in the ``south_migrations`` package.
"""
SOUTH_ERROR_MESSAGE = """\n
For South support, customize the SOUTH_MIGRATION_MODULES setting like so:
SOUTH_MIGRATION_MODULES = {
'wfp_auth': 'wfp_auth.south_migrations',
}
"""
# Ensure the user is not using Django 1.6 or below with South
try:
from django.db import migrations # noqa
except ImportError:
from django.core.exceptions import ImproperlyConfigured
raise ImproperlyConfigured(SOUTH_ERROR_MESSAGE)
```
I have done the migration from 1.6 to 1.7 on an existing project. It was fairly painless.
I renamed my old South migrations folders and let the django 1.7 migrations create a new one. (i.e. $mv appname/migrations appname/migrations.south) That will make it easier to go back to South for any reason and will keep from having a jumbled mess of both in your migrations folders.
Related
I have a Django 1.11 project and I'm trying to squash all migrations by deleting and re-making all of them.
However, when I go to run manage.py makemigrations I get an error like:
ValueError: The field app1.Model1.campaign was declared with a lazy reference to 'app2.Campaign', but app 'app2' isn't installed.
However, app2 is definitely installed. I even print out my INSTALLED_APPS list in my settings.py to confirm it is. What's causing this error?
I have 2 related questions.
I have deleted all my migrations, including the migrations directory, from all the apps in my project. I've started with a clean database. But still, when I run ./manage.py makemigrations, django says there are no changes to be made. How do I completely start over with migrations? No squashing, just starting over.
It seems that when I call makemigrations, django consults the database. I'd like my codebase to be the only source of truth for my migrations. Is there a way to do this?
If an app doesn't have a migrations/ directory with an __init__.py file (even on Python 3), Django won't create any migrations if you don't specify the app name. You either have to create the directories and __init__.py files, or you have to call ./manage.py makemigrations <app_name> for each app, which forces Django to create the directory.
It doesn't. It may connect to the database during the makemigrations command, but the migrations are purely based on your models.
I'm upgrading a django project from 1.6.11 to 1.7.9. I use DRF 2.4.4. Once everything is working fine, I'll upgrade to DRF 3.x
I started using django-oauth2-provider, but it can not work with django 1.7, so I'm moving to django-oauth-toolkit.
for the record, it does not work because HttpResponse does not accept mimetype anymore. it has to be 'content_type'. PRs for django-oauth2-provider are abandoned.
I pip installed it and added the oauth app to INSTALLED_APPS. Their docs suggest using syncdb and then migrate, although Django 1.7 deprecated syncdb. I tried to migrate it with ./manage migrate oauth2_provider unsuccessfully. It keeps reporting:
ValueError: Dependency on unknown app: provider
provider happens to be the old module for oauth, that was coupled with 2 of my apps.
I removed it from INSTALLED_APPS, commented all imports and usages of its classes, changed the model that had a FK to provider.oauth2.models.Client (I removed that field), and tried again. I got the same error.
The initial migration of one of the apps seems to be the only valid code that uses provider :
class Migration(migrations.Migration):
dependencies = [
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
('contenttypes', '0001_initial'),
('provider', '__first__'),
]
however, after this migration I removed that field. With South I'd probably do ./manage.py schemamigration myapp --auto and then migrate.
However, when I try to makemigrations myapp I get the same error.
I'm totally lost. How can I get rid off the old oauth module and get the new one? Do I have to run makemigrations for oauth2_provider or just migrate? My guess is that only migrate. Why can't I make a migration with the changes in myapp model?
This has happened to me. Try manually removing the "provider" app line in initial migration that refers to it. Alternately, you can delete all migrations and run "makemigrations" from scratch (remember, for initial migrations you have to do it once for every individual app).
I am a newbie and a new user to Django and South. I created a new model (approval.py) in my models package (and linked it in model's init.py) and was able to successfully migrate my app to accept the new model. However, when I tried looking for that model on the admin site, I was getting a 403 forbidden error since the Guardian permissions were not applied.
So I directly dropped the table from sqlite command prompt and tried to perform the following commands again:
$python manage.py syncdb
...
(use ./manage.py migrate to migrate these)
$python manage.py schemamigration myapp --auto
Nothing seems to have changed.
$python manage.py migrate myapp
Running migrations for myapp:
- Nothing to migrate.
- Loading initial data for myapp.
Installed 0 object(s) from 0 fixture(s)
However, the table is no longer getting created, when I check in sqlite command prompt. Also, I had registered this model on my admin.sites.url, but it is no longer displaying it and giving error as:
DatabaseError at /admin/myapp/approval/
no such table: myapp_approval
Request Method: GET
Request URL: http://localhost/admin/approval/
Django Version: 1.5.1
Exception Type: DatabaseError
Exception Value:
no such table: myapp_approval
Exception Location: /home/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py in execute, line 362
Python Executable: /home/bin/python2.7
Python Version: 2.7.5
Python Path:
['.........']
Server time: Wed, 9 Jul 2014 19:12:00 -0500
I have already checked all the other questions posted on StackOverflow about using South for migrations, in particular the error about "Nothing seems to have changed". However I am not able to resolve my issue with any of those solutions.
I kindly request some help in either :
Creating the approval model again from scratch and migrating it successfully
Or Repairing the existing approval model.
Thanks.
Finally after a lot of trial and error, something very simple worked for me. I did not have much luck with the south migrations. So as I had manually dropped the table from sqlite3, I decided to manually create the table in sqlite3 and everything worked perfectly fine.
I used the below script on the sqlite3 prompt and it solved my issue and I was able to access the approval page correctly through my admin site and perform all CRUD operations on it.
CREATE TABLE "myapp_approval" ("id" integer NOT NULL PRIMARY KEY, "desc" varchar(256) NOT NULL);
Thanks everyone for your help and support!
You have already created a migration that creates the new table, and according to South's history management, you've run this migration. South does not know about the actual changes to your database.
What you need to do is to revert to a migration before the new table was created. If you look in your apps folder, you'll find a migrations folder with some migration files in it. If you created the new table in e.g. migration 0005, you need to (optionally) migrate backwards to 0005, and then you need to fake a backwards migration to 0004 and migrate again:
manage.py migrate myapp 0005
manage.py migrate myapp 0004 --fake
manage.py migrate myapp
I have a Django project on a Centos VPS.
I created some models and debugged them so they validate and give no errors.
I have them in a "models" folder in my myapp and have added each model to the init file in this directory, for example:
from category import Category
I added the app to settings.py INSTALLED_APPS and ran:
Python manage.py syncdb
It appeared to work fine and added all tables apart from the ones for my app.
I then installed South and added that to INSTALLED_APPS and, tried syncdb again and ran:
Python manage.py schemamigration myapp --initial
It generated the file correctly but nothing was in it (none of the tables my models).
An example file in "models" folder (usertype.py)
from django.db import models
class UserType(models.Model):
usertype_id = models.PositiveIntegerField(primary_key=True)
description = models.CharField(max_length=100)
is_admin = models.BooleanField()
is_moderator = models.BooleanField()
class Meta:
app_label = 'myapp'
Any ideas what could be going wrong here and why I can't get anything to detect my models?
Run the following commands
python manage.py makemigrations yourappname
python manage.py migrate
Note it works on django 1.7 version for me.
you're misunderstanding the process of working with south. South isn't just another application, it's a managing tool. Your app needs to be a South application from the begining or converted to one. That being said, the process is like so:
Add South to INSTALLED_APPS
run syncdb for the first time
Add your app to INSTALLED_APPS*
run the south initialization command:
python manage.py schemamigration myapp --initial
migrate:
python manage.py migrate
If you want to convert a project:
Run syncdb after adding south
run:
manage.py convert_to_south myapp
And use south from now on to manage your migrations.
*p.s. - you can add both south and your own app at the same time, if you keep in mind to put south before your own apps. That's because django reads INSTALLED_APPS in order - it runs syncdb on all apps, but after installing south it won't install the rest and instead tell you to use the south commands to handle those
edit
I misled you. Since you put so much emphasis on the south thing I didn't realize the problem was you were trying to use models as a directory module instead of a normal file. This is a recognized problem in django, and the workaround is actually exactly as you though in the first place:
say this is your structure:
project/
myapp/
models/
__init__.py
bar.py
you need bar.py to look like this:
from django.db import models
class Foo(models.Model):
# fields...
class Meta:
app_label = 'myapp' #you need this!
and __init__.py needs to look like this:
from bar import Foo
Make sure it looks like this and it will work.
UPDATE 18/08/2014
The ticket has changed to wontfix, because apparently the bigger issue with the app_label has been fixed. Huzza!