Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc database improvement suggestions #5093

Merged
merged 4 commits into from
Jun 26, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 26 additions & 26 deletions doc/integrator/database.rst
Original file line number Diff line number Diff line change
@@ -1,46 +1,46 @@
.. _integrator_database:

========
Database
========

To be able to do a rollback the integration and the production data should be in the same database,
but the schema will be different.
Update lifecycle
----------------
The recommended setup is to have integration and production data on the same database, using
separate schemas. This setup allows for simpler switches between integration and production.

For the static schema will have one for the integration and one for the production environments, e.-g.:
The recommended setup for the ``static`` schema is to have exactly one schema for integration
and one for the production, e.-g.:
``integration_static`` for the integration environment,
and ``production_static`` for the production environment.

For the main schema will have one for each version of the application. We will have the following livecycle:

Current version:
integration and production => ``main_2017``

Start an upgrade (application or admin (layertree)), create an new schema and use it on integration:
integration = ``main_2018``, and production => ``main_2017``

Do the changes or the upgrade.

Publish the new version:
integration and production => ``main_2018``

The schema ``main_2017`` still exists to be able to rollback the production.
For the data of the ``main`` schema, we recommend to have one schema for each version of the application.
The following example shows how an update can be performed from a version ``2017`` to a version ``2018``:

To do that we should manage the ``PGSCHEMA`` and the ``DOCKER_PGSCHEMA_STATIC`` variable in your
makefiles.
* Starting point is that the current version is the same on integration and production => ``main_2017``
* When starting the changes, such as an application change and/or administration settings,
create a new schema ``main_2018`` and use it on integration. Now, integration uses ``main_2018``,
while production still uses ``main_2017``.
* Do the changes or the upgrade.
* Publish the new version on production: now, integration and production both use ``main_2018``
* The schema ``main_2017`` still exists, so if needed, the production can be rolled back to this content.

The ``PGSCHEMA`` should be set in the ``Makefile`` and the ``DOCKER_PGSCHEMA_STATIC`` for the
production should be set in a specific makefile for the production e.-g. ``production.mk``.
To be able to proceed like this, the variables ``PGSCHEMA`` and the ``DOCKER_PGSCHEMA_STATIC``
should be managed in your makefiles:

And the line `PGSCHEMA=${docker_schema}` should be removed from your `.env.mako` file.
* the ``PGSCHEMA`` variable should be set in the ``Makefile``.
* the ``DOCKER_PGSCHEMA_STATIC`` variable for the production should be set in a specific makefile for the production e.-g. ``production.mk``.
* the line ``PGSCHEMA=${docker_schema}`` should be removed from your ``.env.mako`` file.

To copy the schema, we provide a Postgres function, to create it use:
Copying a schema
----------------
To copy a schema, `c2cgeoportal` provides a Postgres function called `clone_schema`.
If you have not created it in your database, use to following command to create this function:

.. prompt:: bash

docker-compose exec geoporal psql <database> --file=scripts/CONST_clone_schema.sql
docker-compose exec geoportal psql <database> --file=scripts/CONST_clone_schema.sql
jwkaltz marked this conversation as resolved.
Show resolved Hide resolved

To use it:
To use the function, connect to your database and perform the following statement:

.. code:: sql

jwkaltz marked this conversation as resolved.
Show resolved Hide resolved
Expand Down