This can be problematic if the id is not unique on the remote portal. It should not happen on the CKAN side, but it will break in at least the following case:
a dataset with a given resource id is harvested, then deleted on remote side
the dataset is automatically archived (but not deleted) on udata's side
a new dataset appears with the same resource id on the remote side
a new dataset and resource is created with the same resource id as the previous one which still exists on udata's side
➡️ this leads to an id conflict and for example the stable resource URL will point to the obsolete resource URL
protect the harvesting process against conflictual IDs: raise an error for a given dataset if it contains an existing resource id ➡️ easier to implement but requires a manual action (dataset deletion) to fix the situation
We're currently using the remote resource id for our own resource id https://github.com/opendatateam/udata-ckan/blob/a7c5f4e67311152b066d697fc8899d5941b1f6d4/udata_ckan/harvesters.py#L250
This can be problematic if the id is not unique on the remote portal. It should not happen on the CKAN side, but it will break in at least the following case:
Possible solutions:
resource.extras.harvest:remote_idto map the the remote resource to the local one https://github.com/opendatateam/udata-ckan/blob/a7c5f4e67311152b066d697fc8899d5941b1f6d4/udata_ckan/harvesters.py#L245 — the local resource will have an auto-generated resource id, which should be unique ➡️ this is nice but we need quite some code changes and a migration