We have a Django application that has been in production since Django 1.1. Over the years, we've manually added bells and whistles to the production PostgreSQL db that weren't at the time overtly supported by Django's db automation, especially in the form of custom indexes.
Django's come a long way since 1.1, and now w/ 1.10 I'm pretty sure the migration framework supports all the custom features we've added manually. Is there any automated tool which will compare a database to the models, and generate migrations to bring the models up to date with the db?
This is built into django, you can just run inspectdb
manage.py inspectdb
Introspects the database tables in the database pointed-to by the NAME setting and outputs a Django model module (a models.py file) to standard output. You may choose what tables to inspect by passing their names as arguments.
Use this if you have a legacy database with which you’d like to use Django. The script will inspect the database and create a model for each table within it.
Related
Let's say that we have a Django app that looks on a legacy database.
If someone make changes on some database tables from a db client as DBeaver for example and not through Django models, is there a way to identify these changes?
You can do in a terminal, inside your Django project directory : python manage.py inspectdb > models.py
You will have models related to your tables.
By default, inspectdb creates unmanaged models. That is, managed = False in the model’s Meta class tells Django not to manage each table’s creation, modification, and deletion.
If you do want to allow Django to manage the table’s lifecycle, you’ll need to change the managed option above to True (or remove it because True is its default value).
I'm using Django for backend, but for some reason, I want to use Laravel beside Django and share the database between them. so the same database for Django and Laravel. but the problem is that Django migrations are not equal to Laravel migrations so the database is different from ( for example constraints and indexes and some other options).
Is this going to break backend if I use Django as the primary database and use Laravel as a secondary backend?
If true, how I can use Django and Laravel in the same database?
Your database does not depend on Django or Laravel. It just stores data.
Constraints, triggers, indexes, etc are stored on the database itself, and they are completely independent of your framework. Frameworks just abstract the methods and provide easy methods to manage your database. At the core, they use the same commands which are provided by the database. The names of constraints are irrelevant, you can give whatever names you want, frameworks just provide their own uniform naming pattern, which can be customized by the user. So they can be used on both Django and Laravel or any other framework/programming language. That's the main purpose of having a database, to store data in a structured manner so it can be used by any language/framework
Since you already have migrations in Django, there's no need to create the migrations again in laravel. Just reuse the Django database and make your laravel application to properly handle the data (that part is completely in your control)
I am working on already existing data on relational database. Now question is that how to build models and how to update the tables with new data coming from user (technically django forms)?
Django natively supports creating models for and working with existing data. From the documentation:
Integrating Django with a legacy database
Django will still need to create several of its own tables, but will adapt to use your existing tables. From the doc, you can auto-create models like this:
python manage.py inspectdb > models.py
You'll need to determine whether you want to manage updates to the table structure, but that's getting into details that will be specific to your project.
I spin up a django project. Afterwards, i didn't write models.py but instead I created a database from MySQL command line(independent from django) and created three tables with required columns. Finally i connected my django app with that database successfully. I applied migrations. But now i am confused do i need to write models.py with every field name as in column?
I remember implementing a basic project in which i did write models.py and created database using "python manage.py shell" and then put values using
"from polls.models import Choice, Question"? How do i put data now initially and then using python on some action from UI?
Do i need models.py even for ready made mysql databases?
You do not need to construct models. Some (small) webservers are even completely stateless, and thus do not use a database. But a large part of how Django can help you is based on models.
You can write your own queries, forms, etc. But often by using a ModelForm, Django can for example remove a large amount of boilerplate code. It will make it furthermore less likely that there are mistakes in your code. So although not strictly necessary, the models are usually a keystone in how Django can help you.
You can use the inspectdb [Django-doc] command to inspect the database, and let Django "sketch" the models for you. Usually you will have still some work. Since Django can, for example, not derive that a field is an EmailField, since both a CharField and EmailField look exactly the same at the database side.
You do not need to use inspectdb however. You can construct your own models. If you create your own models, but these exist already at the database side, you might want to set managed = False [Django-doc] in the Meta of your model, to prevent Django from constructing migrations.
We have a django app that is running in production.
It used to run django 1.4.3 against a mysql database.
We had all our migration scripts using django south.
We recently upgraded to django 1.11.6. Along with it we moved the data to a postgres database.
The app runs fine, but the migration scripts that are generated using django migrations by using the django models are not fully consistent with the existing schema.
Almost all of the differences seem to be in the index names that are generated.
What are our options to make the django migrations and the database consistent? How do we go forward with this?
Should we generate a new empty database using the django migrations, and migrate the data from the old to the new empty database?
I know we can edit the models.py and set the index names manually but that is too cumbersome, we need to edit hundreds of models; is there an easy way to do that?
Is there a way I can generate the migration scripts from the existing database, and verify if the models are compatible?