How to store third party apps migrations in django - django

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.

Related

reusable app (package) in Django - how to add extra models

I am writing a small package that extends the django app that is used by many of my colleagues locally. So right now they can simply add it via pip, and then they add this extension in INSTALLED_APPS in settings.py.
But the problem is that I can't add the new models to this extension (or at least I don't figure out yet how to do it correctly) because then the guys who would like to use my extension, have to sync their database or make migrations so their database contains the models needed for extension.
Is it possible (and right thing to do) to add new models to the current django project 'silently' as soon as the user adds the app to INSTALLED_APPS?

Migrate models outside current app

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.

CMS for Django when upgrading app from 1.5.5 to 1.7.1

I have a huge... challenge in front of me. For about a week or two I've been migrating 1.5.5 django project to 1.7.1. A huge jump, many deprecated variables, methods and so on.
In 1.5.5 there were some south migrations done but not everywhere, as it was not implemented from the beginning. So let's say there are no migrations, they have to be created.
Also there is a wish to add a cms to the already upgraded project, but with django-cms-3.0.7 I constantly encounter some issues with migrations, south existing etc.
Is there a CMS that I can use with this app that won't be bothered by migrations and django version?
All I want to edit is the static content (text, images, maybe adding videos) before user logon. No integration with models. Just some info pages.
Any suggestions?
A maybe oversimplified solution for this could be django-front. Create your static pages and add the fields you want to edit. You edit it with a wysiwyg editor. I use it for my terms of service/privacy policy.
You will probably be always bothered by migrations and django version when using an app that brings extra functionality, but the apps should not be hard to upgrade and normally they have a warning/walk through when an important change on their arquitecture/functionality has happened.
That being said, i don't think migrations change dramatically now. The change to include them in the django project was an important (and needed) one.
If you want something even more simple (and time resistant) just create a model for your pages and render it on your template:
class Content(models.Model):
html_content = models.TextField()
image_content = models.ImageField()
Register that model to your admin and that should do the trick. For simple applications this may be enough.

Django 1.7 - makemigrations creating migration for unmanaged model

I am creating some dynamic Django models in my application and everything seems to be working as expected except for the migration system.
If I create a dynamic Django model and set managed = False, Django's makemigrations command still generates a migration for that new model. The migration looks something like this:
class Migration(migrations.Migration):
dependencies = [
('atom', '0001_initial'),
]
operations = [
migrations.CreateModel(
name='books',
fields=[
],
options={
'db_table': 'books',
'managed': False,
},
bases=(models.Model,),
),
]
If I don't create the migration, when I run python manage.py migrate, I see the following message (in big scary red letters):
Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
Is there a way to tell the migrations system in Django 1.7 to ignore unmanaged models all together? or perhaps a migrations = False setting in the Meta class of the models?
UPDATE: for clarification, I am using a method to create my dynamic models similar to the ones describe in the following places:
http://dynamic-models.readthedocs.org/en/latest/topics/model.html#topics-model
https://code.djangoproject.com/wiki/DynamicModels
This method is great for generating my dynamic models based on information stored in my Configuration models (https://code.djangoproject.com/wiki/DynamicModels#Adatabase-drivenapproach). I did have to register a signal to clear the django model cache to catch changes to the models when a Configuration instance is changed, but everything seems to be working great, except for the fact that migrations are generated for these models. If I delete one of the configurations and the model is deleted from Django's cache, the migration would need to be updated again, removing the model that it shouldn't care about.
These dynamic models are not used in the application specifically. No where in the code do I refer to a books model (from the example above). They are generated at runtime and used to read information from the legacy tables they provide access to.
The short answer is that Django is not built for this. Making your model "unmanaged" only means Django will not create or delete the table for it -- nothing else.
That said, if you have no regular models alongside these dynamic models in the same app, you can conditionally add the app to INSTALLED_APPS in settings.py:
if not ('makemigrations' in sys.argv or 'migrate' in sys.argv):
INSTALLED_APPS += (
'app_with_dynamic_models',
'another_app_with_dynamic_models',
)
This should make Django ignore the app when creating and running migrations. However, you will eventually have to make and run migrations for the models if you want to use them, since the ability to have apps which do not use migrations is meant to go away in Django 1.9. Could your dynamic models be refactored to use the contenttypes framework?
I suggest you replace the generated migrations.CreateModel operation by one of your own that always reflect the actual model state. This way no state changes should be ever detected.
class CreateDynamicModel(CreateModel):
def __init__(self):
# ... dynamically generate the name, fields, options and bases
super(CreateDynamicModel, self).super(
name=name, fields=fields, options=optins, bases=bases
)
You can probably write a custom database router with the allow_migrate method returning False for your dynamic models. The migrate command will disallow them in that case.
As long as you don't load these dynamic models in any models.py module, makemigrations shouldn't pick them up either.

South does not recognize models when it is a package

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.