Update - Utiliser les UUID

[camillemonchicourt]

Il était initialement prévu de se baser sur les UUID des objets dans la synthèse pour mettre à jour les données si elles ont été modifiées dans la source.

Cependant, toutes les données d'un GeoNature n'ont pas forcément d'UUID et cela doit rester possible. Voir PnX-SI/GeoNature#1205

Cependant les UUID sont vraiment idéaux pour les échanges automatiques entre outils et notamment pour GN2GN.

Du coup peut-être à approfondir. Ou alors se baser sur les UUID sans les imposer ? Si une données n'a pas d'UUID dans la source, alors elle n'est pas transmise lors d'un GN2GN ?

[lpofredc]

Au regard de la généricité de l'application, il n'est finalement pas si pertinent de se restreindre aux UUID, l'appli permettant d'importer d'autres types de donnée fournies par le module d'export. En revanche, on peut en effet très bien envisager d'exclure les données de synthèse sans UUID, car non traçable dans le cadre d'échanges.

[lpofredc]

Les données à mettre à jour (Insert, Upsert, Delete) côté GeoNature client sont identifiées par le couple source/id donnée:

• gn2pg source = gn_synthese.t_sources.name_source
• id de la donnée = gn_synthese.synthese.entity_source_pk_value

Les sources de gn_synthese.t_sources sont automatiquent générées et la correspondance se fait sur le champ name_source:

GN2PG/gn2pg/data/to_gnsynthese.sql

Lines 124 to 151 in ad01129

	CREATE OR REPLACE FUNCTION gn2pg_import.fct_c_get_or_insert_source(_source TEXT)
	RETURNS INTEGER
	AS
	$func$
	DECLARE
	the_source_id INT;
	BEGIN
	INSERT INTO gn_synthese.t_sources (name_source)
	SELECT
	_source
	WHERE
	NOT exists(
	SELECT
	1
	FROM
	gn_synthese.t_sources
	WHERE
	name_source = _source);
	SELECT
	id_source
	INTO the_source_id
	FROM
	gn_synthese.t_sources
	WHERE
	name_source = _source;
	RETURN the_source_id;
	END
	$func$

[bouttier]

Bonjour Fred,
Plusieurs remarques :

• entity_source_pk_value ne possède pas de contrainte NOT NULL, pas plus que le champ unique_id_sinp. Il est donc tout aussi hasardeux de se fonder sur ce champs.
• Il ne semble pas souhaitable d’importer les sources d’une instance A vers une instance B. En effet, les sources sont des informations locales, par exemple Import(id=42). Cela peut venir en conflit avec les sources locales. Cette information a également peu d’intérêt sur l’instance de destination.
• Il me semble plus pertinent de créer une unique source pour chaque instance que l’on synchronise, par exemple une source « Données synchronisé depuis geonature.XXX.fr ». Et sur l’instance de destination, l’entity_source_pk_value reçoit l’id_synthese de l’instance d’origine.
• Il est ainsi possible de comparer l’id_synthese d’origine avec l’entity_source_pk_value locale lors des synchronisation ultérieur. Et on a la garantie que l’id_synthese est toujours bien définie.

[lpofredc]

Bonjour @bouttier,

* Il ne semble pas souhaitable d’importer les sources d’une instance A vers une instance B. En effet, les sources sont des informations locales, par exemple `Import(id=42)`. Cela peut venir en conflit avec les sources locales. Cette information a également peu d’intérêt sur l’instance de destination.

il semble y avoir un léger quiproquo sur le volet source, la source de gn2pg est le nom de la source dans le fichier de config de l'appli et non la source du GeoNature fournisseur de donnée.

* Il me semble plus pertinent de créer une unique source pour chaque instance que l’on synchronise, par exemple une source « Données synchronisé depuis geonature.XXX.fr ». Et sur l’instance de destination, l’`entity_source_pk_value` reçoit l’`id_synthese` de l’instance d’origine.

cf. remarque précédente. c'est bien le cas. charge à chacun de les nommer explicitement, le champ source est un varchar simple).

* Il est ainsi possible de comparer l’`id_synthese` d’origine avec l’`entity_source_pk_value` locale lors des synchronisation ultérieur. Et on a la garantie que l’`id_synthese` est toujours bien définie.

Oui, c'est bien ce qui se passe.

[bouttier]

Ok super, je n’avais pas compris le comportement !