You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OK so I have a database with some PK -> FK constraints and my workflow is:
Load the db schema in postgres
Load some fixtures in postgres
Init from DB
Push to mergin cloud
Pull to QGIS Desktop (using a separate working dir to the one db sync uses)
Make some edits (add a plant type, add a vegetation point) in QGIS
Sync from QGIS Desktop to mergin cloud
Use mergin-db-sync to try to pull the changes back from cloud to my pg database
This process fails because it tries to insert the vegetation point record before it has created the needed plant type record.
Here is the log of my process:
# Just a clean up in case we had the db already
# NOTE: Also remove the GPKG from the mergin cloud instance and commit the change
PGSERVICE=osgs.kartoza.com psql -c "drop database farming;" postgres
# Grab the schema
wget -O farming.sql https://raw.githubusercontent.com/kartoza/smallfarming-gis/main/sql/farming.sql
# Load the schema
PGSERVICE=osgs.kartoza.com psql -c "create database farming;" postgres
PGSERVICE=osgs.kartoza.com psql -f farming.sql farming
# Grab the fixtures
wget -O fixtures.sql https://raw.githubusercontent.com/kartoza/smallfarming-gis/main/sql/fixtures.sql
# Load the fixtures
PGSERVICE=osgs.kartoza.com psql -f fixtures.sql farming
# Verify db state (list schemas, list tables)
PGSERVICE=osgs.kartoza.com psql -c "\dn" farming
PGSERVICE=osgs.kartoza.com psql -c "\d" farming
# This is mergin-db-sync's folder, it will get recreated in the line after
rm -rf /home/timlinux/gisdata/MerginSyncProjects/farming/
python dbsync.py init-from-db
rm -rf ~/Syncthing/QGISProjects/MerginMapsProjects/farming
# Now do steps 5,6,7 in my QGIS Desktop, checking out the project to the folder above
python dbsync.py pull
Here is the log from the last (step 8 above) pull command:
Ordering of table inserts/updates/deletes to avoid this would be probably very tricky, fortunately there is an alternative solution: constraints such as foreign keys can be deferred, so they are not evaluated immediately after each insert/update/delete, but only at the end of the transaction.
There are three valid options for constraints:
NOT DEFERRABLE - if it can not be deferred at all (the default)
DEFERRABLE INITIALLY IMMEDIATE - it can be deferred, but it has to be explicitly enabled in transaction
DEFERRABLE INITIALLY DEFERRED - it can be deferred, and it is set as deferred initially in transactions
So the SQL creating tables can be modified from this:
infrastructure_type_uuid UUID NOT NULL REFERENCES infrastructure_type(uuid)
to something like this:
infrastructure_type_uuid UUID NOT NULL REFERENCES infrastructure_type(uuid) DEFERRABLE INITIALLY DEFERRED
Then the problem should go away. Foreign key checks are still enabled, but only evaluated at the end of transaction when everything should be in order.
Things worth improving in geodiff / db-sync on this matter:
detect if there are any foreign keys that are not deferrable
support also DEFERRABLE INITIALLY IMMEDIATE by running SET CONSTRAINTS ALL DEFERRED; at the start of a transaction
OK so I have a database with some PK -> FK constraints and my workflow is:
This process fails because it tries to insert the vegetation point record before it has created the needed plant type record.
Here is the log of my process:
Here is the log from the last (step 8 above) pull command:
The text was updated successfully, but these errors were encountered: