unique index on id_source, entity_source_pk_value not wanted

[DonovanMaillard]

This unique index can bring some problems for example if we import SINP data from INPN in the instance. A unique source wich contains data from several external sources, with possibly the same entity pk value.

[DonovanMaillard]

I think it will also make problems on ORB database, because gn2pg will work on already agglomerated data into thematic databases.

For example, invertebrates data published by the thematic pole will come from several sources, have non-unique pk_values, and come from the same source "pole invertébrés" in the ORB database.
It would be more efficient to base on uuid field I think.

[lpofredc]

complex issue with conflicting expectations, as mentioned in question #31.

It may could be solved by working on the triggering rules, preferably using the uuid or, if no uuid is available, the source/entity_source_pk_values pair as the data identifier.

Does this raise the question of the use of the entity_source_pk_value field? In GN2PG's SQL examples, the entity_source_pk_value of the destination database is the id_synthese of the source database. So, there is normally no duplicates but makes it more difficult to trace the source of the data without UUID.