I use South for schema and data migraton for my Django site. I'm happy about using it. One day I converted models.py file to models/__init__py and put some additional models at models/something.py. When I ran python manage.py schemamigration app --auto, I got the Nothing seems to have changed. message despite of the new classes at something.py. If I copied them to the __init__py file, South had recognized the new models. I tried to import everything from something in the top of __init__py, but no change.
It's Django design. Django is not picking your models at all, you need to set app_label in your model's Meta class.
See ticket on Automatically discover models within a package without using the app_label Meta attribute.
Related
I'm building a project using django v2.0.2 that consists of 3 apps with 24 models. One of the apps has 14 models. Having so many models in one app is becoming complicated, and I'd like to create a new app and move few models to this app.
I found an answer explaining how this can be done using south. I've been using django core migrations and since south is deprecated, I don't want to switch to south at this point.
The models I want to move are quite complex - they have ForeignKey fields, ManyToMany fields, etc. I need a workflow showing how I can move these models using django core migrations.
That shouldn't be too difficult to do. The main issue you run into is that Django automatically derives the name of the database table from the name of your model class and the app that contains it.
That means unless you're explicitly setting the db_table property in the model meta, the names of all the tables corresponding to your models are auto generated based on app/model name combo.
So if you have a Post model in a Blog app, the auto generated table name of that Post model is blog_post. And if you decide to move Post model to the Article app, Django will be looking for a table named article_post and won't be able to associate your model with the correct table.
To solve this issue, you need to explicitly set the db_table property on each of the models. The db_table name value will have to correspond to the current app/model combo. So in the case of Post model mentioned above, you would set db_table to blog_post. Once you set the db_table property, you can move the model to any other apps.
class Post(models.Model):
title = models.CharField(max_length=120)
class Meta:
db_table = 'blog_post'
Once you move all the models around, login to django admin to verify that your data is still accessible through the newly moved models.
When you run makemigrations for the first time after moving the models,
Django migrations will create migration files that deletes the moved models in their old app and recreate them in their new app. Do not apply these migrations and instead run migrate --fake which will record the migrations as having been executed without making any of the database changes. After that, your migration files and your database structure will be synced.
I'm fairly new to python and django, and trying to build a simple calendar based on django-scheduler package.
According to django-scheduler docs, a custom base class can be used to add additional fields, managers and such.
So, I used an abstract model to add a new field:
#myproject/customer_calendar/models.py
from django.db import models
from main.models import Customer
class CalendarAbstract(models.Model):
customer = models.OneToOneField(to=Customer, null=True, blank=True, related_name='calendar')
class Meta:
abstract = True
And added this to settings.py
SCHEDULER_BASE_CLASSES = {
'Calendar': ['customer_calendar.models.CalendarAbstract'],
}
Now, if I use makemigrations command, a new migration is created inside scheduler app (which is located in site-packages of the current virtual env), which doesn't allow me to keep track of migrations via VCS.
I've found a couple of solutions:
1) Keep the whole scheduler app inside my project. According to SO it' s considered a bad practice and third-party apps should always be retrieved via pip.
2) Use django setting to store all django-scheduler migrations inside my calendar app
MIGRATION_MODULES = {
'schedule': 'customer_calendar.migrations',
}
The second one looks good to me, but I don't know if it's considered to be a valid solution to this problem.
Is there any other ways to store third-party apps migrations?
The second one looks good to me, but I don't know if it's considered
to be a valid solution to this problem. Is there any other ways to
store third-party apps migrations?
As also stated in this answer, FeinCMS docs recommend the use of MIGRATION_MODULES to monitor the migrations of FeinCMS as a third-party app.
FeinCMS itself does not come with any migrations. It is recommended
that you add migrations for FeinCMS models yourself inside your
project.
...
Create a new folder named migrate in your app with an empty init.py inside.
Add the following configuration to your settings.py:
MIGRATION_MODULES = {
'page': 'yourapp.migrate.page',
'medialibrary': 'yourapp.migrate.medialibrary', }
You must not use migrations as folder name for the FeinCMS migrations,
otherwise Django will get confused.
I'm using django-modeltranslation in a Django 1.8 project. This app generates fields on the fly to store translations. It's possible to mark models as translatable by creating an Options class, like registering models with the Django admin.
I marked a model from a third party app as translatable. Django's migrations system picks up the changes and generates migrations in the app outside of my project. I want to store these migrations in an app in my project, how can I do that? I can only give a model name to migration operations, not a fully qualified app name.model name string.
I created my database using python manage.py syncdb And I tried to add another attribute to my model called created_date My site gives error. And I deleted my db.sqlite3 file Then reorganize my model Then error went. I want to know is this correct
As the comment says migrations are the way to do this. Native migrations were only introduced in Django 1.7 but, since you're using syncdb, I'm guessing you're using an earlier version.
For earlier versions of Django you need a third-party app called South to handle migrations for you. This will then let you change your database after creation fairly painlessly in most cases.
I have a custom app which I wanted to start using South with. It uses a FK for associating a blog entry from another app (proprietary, not written by me). Problem is when I try to run the initial schemamigration I get an error that some of the blog entry app's fields cannot be frozen. The fields that can't be frozen are fields that uses custom fields extended off of the core fields.
./manage.py schemamigration free --initial
I read South's docs on extending introspection but I don't know where/how to define the introspection rules.
Thanks in advance for any suggestions.
Have you tried the South Field Triple approach instead?