A methodological guide to Django and legacy database consolidation

The Django database layer generates SQL schemas-from Python code but for legacy databases, you already have SQL schemas. In this case, you need to create a model for a data table that already exists. To do this, Django comes with a tool that can generate model by reading your data table structure. This helper is called Inspectdb, and you can invoke it by executing the manage.py inspectdb.
using Inspectdb

The INSPECTDB tool introspection the database to which you are configuring the file, generates a Django model for each table, and then displays the code for these Python models in the standard output of the system.

The following is a starting from scratch for a typical legacy database consolidation process. Two prerequisites are the installation of Django and a traditional database.

Build a Django project by running django-admin.py Startproject MySite (here MySite is the name of your project). OK, so we'll use this mysite as the name of the project in this example.

Edit the configuration file in the project, mysite/settings.py, and tell Django your database connection parameters and database name. Specifically, to provide these configuration information for database_name, Database_engine, Database_user, Database_password, Database_host, and Database_port: (Note that some of these settings are optional.) For more information, see Chapter 5th)

Create a Django app by running Python mysite/manage.py startapp MyApp (where MyApp is the name of your app). Here we use MyApp as the application name.

Run the command Python mysite/manage.py inspectdb. This examines all the tables in the database_name database and prints out the model classes generated for each table. Take a look at the output to see what inspectdb can do.

Redirect the output of the standard shell and save the output to your application's models.py file:

Python mysite/manage.py inspectdb > mysite/myapp/models.py

Edit the mysite/myapp/models.py file to clean up the generated models and make some necessary customizations.

Clean up the generated models

As you might expect, database introspection is not perfect, and you need to clean up the generated model code a bit. Here is a reminder of the key points for dealing with generating models:

Each table in the database is converted to a model class (that is, the database table and model class are one-to-two mappings). This means that you need to refactor the models to a Manytomanyfield object for many-to-many connected tables.

Each field in the generated model has its own properties, including the ID primary key field. Note, however, that if a model does not have a primary key, Django automatically adds an ID primary key field to it. This way, you might want to remove such lines of code.

id = models. Integerfield (Primary_key=true)

This is not done simply because the rows are redundant, and if your application needs to add new records to these tables, these lines cause some problems.

Each field type, such as Charfield, Datefield, is determined by locating the database column type, such as Varchar,date. If INSPECTDB cannot map a database field to the Model field, it replaces it with the TextField field and adds a python comment "This field type is guessed" after the generated model field. Be careful about this and change the field type if necessary.

If a field in your database cannot find a suitable counterpart in Django, you can safely skip it. The Django model layer does not require that you have to import each column in your database table.

If the name of a column in the database is a python reserved word (such as pass, class, or for, etc.), Inspectdb appends a _field to each property name and sets the Db_column property to the Real field name (that is, pass, class or for, etc.).

For example, if a table contains a column of type int whose column name is for, the resulting model will contain a field such as the one shown below:

For_field = models. Integerfield (db_column= ' for ')

Inspectdb will add a ' field rename after this field because it is a python reserved word '.

If a table in the database refers to other tables (as most database systems do), you need to modify the order of the generated model appropriately so that the references are mapped correctly. For example, the model book has a foreign key for the model author, and the latter should be defined before the former. If you want to create a relationship to a model that has not yet been defined, you can use a string that contains the model name instead of the model object itself.

For Postgresql,mysql and SQLite database systems, INSPECTDB can automatically detect primary key relationships. That is, it inserts primary_key=true in the right place. For other database systems, you must insert such a statement for at least one field in each model, because the Django model requires that you have a primary_key=true field.

Foreign key detection takes effect only for PostgreSQL, and some specific types in the MySQL table. As with other databases, the Foreign key field is automatically born as a Integerfield if it is assumed to be an int column.

