If the UUID has not been set, this step will attempt
to avoid duplication by querying the fileIdentifier and sourceUri.
If an existing record is not located, a new UUID is generated.
But while a number of different possible sources might result in presetting a UUID for the record rather than calling makeUuid, the first source checked (line 177), the "fileIdentifier" which might apply most often to ISO records, is never set to be the UUID of the record: rec.setUuid is never called, and thus makeUuid is called regardless of the existence of a fileIdentifier. To match the intention described in the comment it seems like the code should read:
String sFileIdentifier = schema.getMeaning().getFileIdentifier(); if (UuidUtil.isUuid(sFileIdentifier)) { rec.setUuid(sFileIdentifier); }
Is there a reason why a fileIdentifier that is a UUID might not want to be recognized as the UUID for GeoPortal as an EsriDocID is? Potential for collision? Are we missing something? Is this handled elsewhere in the code? Thanks for the assistance.
We're trying to work out whether this is a bug or a feature. In this file: https://github.com/Esri/geoportal-server/blob/master/geoportal/src/com/esri/gpt/catalog/publication/PublicationRequest.java Lines 166-216, the comment describes the intended functionality as:
If the UUID has not been set, this step will attempt
String sFileIdentifier = schema.getMeaning().getFileIdentifier(); if (UuidUtil.isUuid(sFileIdentifier)) { rec.setUuid(sFileIdentifier); }
Is there a reason why a fileIdentifier that is a UUID might not want to be recognized as the UUID for GeoPortal as an EsriDocID is? Potential for collision? Are we missing something? Is this handled elsewhere in the code? Thanks for the assistance.