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
Every repository that has upgraded to the latest Metacat version will be utilizing hashstore as the backend object store. This means that a dataset's objects and system metadata should no longer require API calls to the MN/CN to retrieve. However, the existing metadig.properties set-up to support hashstore has a hardcoded location.
To support multiple repositories, we need to consider how the metadig-engine obtains the location of a hashstore and its properties. One path could be the re-purposing of an existing redundant parameter (localFilePath) in the signature of the QueueEntry class when a quality check is being submitted to execute.
Investigate, discuss and then implement the changes required to allow a metadig-engine to support multiple repositories (ex. knb and adc) that have hashstore located in the same file system.
The text was updated successfully, but these errors were encountered:
Every repository that has upgraded to the latest
Metacat
version will be utilizinghashstore
as the backend object store. This means that a dataset's objects and system metadata should no longer require API calls to the MN/CN to retrieve. However, the existingmetadig.properties
set-up to supporthashstore
has a hardcoded location.To support multiple repositories, we need to consider how the
metadig-engine
obtains the location of ahashstore
and its properties. One path could be the re-purposing of an existing redundant parameter (localFilePath
) in the signature of theQueueEntry
class when a quality check is being submitted to execute.Investigate, discuss and then implement the changes required to allow a metadig-engine to support multiple repositories (ex.
knb
andadc
) that havehashstore
located in the same file system.The text was updated successfully, but these errors were encountered: