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
The claim_bucket method takes an optional argument. If this argument does not already exist as a key, a UUID is created. However the uuid is created randomly. This means that starting with the same source data, populating two separate filesystems will result in different keys. This is the behaviour with the pairtree store, and is different from the S3 store, for example.
This is particularly a problem with ORDF and creating a back-end storage module that uses OFS. When ORDF saves a graph, the graph has an identifier which is a URI. This is the natural key to use. The current pairtree back-end takes this URI and if it is not already in the urn:uuid namespace, transforms it into that space in a stable way, using uuid3(NAMESPACE_URL, "http://..."). The resulting UUID is then used as a stable key. This means that storing the same graph again, even in a fresh filesystem, will result in the same identifier being used.
Suggested fix:
if key is URI:
if not key.startswith("urn:uuid:"):
new_key = uuid3(NAMESPACE_URL, key)
# save original uri so it can be later recovered
metadata["canonical_uri"] = key
key = new_key
# strip urn:uuid if it is required by the back-end
key = key[9:]
else:
current behaviour
The key generation should probably be factored out of the back-ends so that it behaves the same way across all of them.
The text was updated successfully, but these errors were encountered:
Reported by wwaites.
The claim_bucket method takes an optional argument. If this argument does not already exist as a key, a UUID is created. However the uuid is created randomly. This means that starting with the same source data, populating two separate filesystems will result in different keys. This is the behaviour with the pairtree store, and is different from the S3 store, for example.
This is particularly a problem with ORDF and creating a back-end storage module that uses OFS. When ORDF saves a graph, the graph has an identifier which is a URI. This is the natural key to use. The current pairtree back-end takes this URI and if it is not already in the urn:uuid namespace, transforms it into that space in a stable way, using uuid3(NAMESPACE_URL, "http://..."). The resulting UUID is then used as a stable key. This means that storing the same graph again, even in a fresh filesystem, will result in the same identifier being used.
Suggested fix:
The key generation should probably be factored out of the back-ends so that it behaves the same way across all of them.
The text was updated successfully, but these errors were encountered: