Merge pull request #10851 from camptocamp/backport/10850-to-2.7

[Backport 2.7] Clarify the main/static schema separation, fix some typo

.github/workflows/main.yaml

@@ -195,7 +195,7 @@ jobs:
       - uses: actions/setup-python@v4
         with:
           python-version: '3.10'
-      - run: pip install --user PyYAML==5.3.1 docker-compose==1.29.2 wheel==0.40.0
+      - run: pip install --user PyYAML==5.3.1 docker==6.1.3 docker-compose==1.29.2 wheel==0.40.0
 
       - name: Init Git
         run:

doc/integrator/database.rst

@@ -3,6 +3,17 @@
 Database
 ========
 
+Schema
+------
+
+The database tables are separated in two schemas:
+
+* The 'main' schema, which can be configured with the ``PGSCHEMA`` environment variable, contains the data that can be modified only by the administrator interface.
+* The 'static' schema, which can be configured with the ``PGSCHEMA_STATIC`` environment variable, contains the data that can be modified by the end user through the web application (user password, short links, OAuth token and audit logs, not the editing data).
+
+This separation makes possible to manage the application configuration (the layer tree) on the integration environment, and copy it to the production environment without any risk of overwriting the data modified by the end user.
+
+
 Update lifecycle
 ----------------
 
@@ -39,14 +50,14 @@ Starting point is that the current version is the same on integration and produc
 Prepare the project
 ~~~~~~~~~~~~~~~~~~~
 
-To be able to proceed like this, the variables ``PGSCHEMA`` and the ``DOCKER_PGSCHEMA_STATIC``
-should be managed in your makefiles:
+To be able to proceed like this, the variables ``PGSCHEMA`` and ``PGSCHEMA_STATIC``
+should be managed in your env files:
 
-* The variable ``PGSCHEMA`` should be set in the ``Makefile``; in this example, it will be set to
+* The variable ``PGSCHEMA`` should be set in the ``env.project``; in this example, it will be set to
   ``main_2019``.
-* The ``DOCKER_PGSCHEMA_STATIC`` variable for production should be set in a specific makefile
-  for production e.-g. ``production.mk``; it will be set for example to ``integration_static`` in the
-  Makefile, and to ``production_static`` in the production makefile.
+* The ``PGSCHEMA_STATIC`` variable for production should be set in a specific env file
+  for production e.-g. ``env.production``; it will be set for example to ``integration_static`` in the
+  env file, and to ``production_static`` in the production env file.
 * The line ``PGSCHEMA=main`` should be removed from your ``env.project`` file.
 
 

doc/integrator/docker.rst

@@ -166,7 +166,7 @@ Config:
 
  * ``VISIBLE_WEB_HOST``: The web host visible by the browser e.g.: 'example.com'.
  * ``VISIBLE_ENTRY_POINT``: The web path visible by the browser e.g.: '/main/', default to '/'.
- * ``PGSCHEMA``: The postgres schema, used by MapServer.
+ * ``PGSCHEMA``: The PostgreSQL schema, used to build the access control SQL related to the restriction area.
  * ``GEOPORTAL_INTERNAL_URL``: Used by the print in non mutualize mode.
  * ``TILECLOUDCHAIN_INTERNAL_URL``: Used by the print in non mutualize mode.
  * ``ST_JOIN``: Can be ``ST_Collect`` (default) or ``ST_Union``, ``ST_Collect`` is better for performance but
@@ -175,7 +175,7 @@ Config:
 Geoportal:
 
  * ``VISIBLE_ENTRY_POINT``: The web path visible by the browser e.g.: '/main/', default to '/'.
- * ``PGSCHEMA``: The postgres schema, used by MapServer.
+ * ``PGSCHEMA``: The PostgreSQL schema, used by MapServer.
  * ``AUTHTKT_TIMEOUT``: See: :ref:`integrator_authentication`.
  * ``AUTHTKT_REISSUE_TIME``: See: :ref:`integrator_authentication`.
  * ``AUTHTKT_MAXAGE``: See: :ref:`integrator_authentication`.

doc/integrator/tilegeneration_doc.rst

@@ -25,7 +25,7 @@ One issue we have if we want to generate all the tiles is that the generation ti
 month, especially if we have a high resolution (low if in m/px) on the last zoom level.
 Therefore for the last zoom level we should generate the tiles on the fly
 with a low expiry (4 hours for example).
-We should use metatiles to reduce the number of requests to postgres.
+Meta tiles should be used to reduce the number of requests to PostgreSQL.
 And the tiles should be deleted after the expiry time.
 
 The chosen solution is a combination of two tools: