603c0d03ae
Sub-projects shall now register their independent alembic migrations via entrypoints in setup.cfg, and neutron-db-manage will discover them and run them automatically. If a service or sub-project is specified explicitly, then neutron-db-manage will run on only that service or sub-project. The advanced services project are just special cases of sub-projects. For example, specifying the CLI option '--service lbaas' is the same as specifying '--subproject neutron-lbaas'. Specifying no service or sub-project will cause neutron-db-manage to run the command on neutron and all installed sub-projects. Added and consolidated documentation into devref for alembic migrations. Partial-Bug: #1471333 Partial-Bug: #1470625 Change-Id: I9a06de64ce35675af28adf819de6f22dc832390d
1.7 KiB
Neutron Database Layer
This section contains some common information that will be useful for developers that need to do some db changes.
Difference between 'default' and 'server_default' parameters for columns
For columns it is possible to set 'default' or 'server_default'. What is the difference between them and why should they be used?
The explanation is quite simple:
- default - the default value that SQLAlchemy will specify in queries for creating instances of a given model;
- server_default - the default value for a column that SQLAlchemy will specify in DDL.
Summarizing, 'default' is useless in migrations and only 'server_default' should be used. For synchronizing migrations with models server_default parameter should also be added in model. If default value in database is not needed, 'server_default' should not be used. The declarative approach can be bypassed (i.e. 'default' may be omitted in the model) if default is enforced through business logic.
Database migrations
For details on the neutron-db-manage wrapper and alembic migrations, see Alembic Migrations.
Tests to verify that database migrations and models are in sync
neutron.tests.functional.db.test_migrations
_TestModelsMigrations