Inside the Store there could be methods to link the ID to a static unique (GUID style) ID. These methods would allow for a graph ID to be changed whilst keeping the GUID the same.
Why do you want this feature?
It would make implementing graph IDs changes in future Gaffer Stores much easier.
Stores which make use of a separate system for providing backing storage to store graph data (currently only the Accumulo Store) do not have a standardised approach for how to identify data associated with different graphs. For example, in Accumulo data for a Gaffer graph is stored in an Accumulo table with a table name the same as the Gaffer graph ID. This works so long as the Gaffer graph ID doesn't change. If a graph's ID needs to be changed, this also necessitates a change to the Accumulo table name associated with that graph. With the GUID approach above, the Accumulo table name would always be unique and wouldn't need to be changed - only the mapping from graph ID to GUID would change.
Describe alternatives you've considered
Continuing to have ad-hoc management of this in individual stores with custom code in the Federated Store to facilitate graph ID changes.
Additional context
See #2495 for context. While the Accumulo Store is used as an example above, it would be breaking to remove the current method.
Re-adding an existing graph (where data already exists) is a use case which relies on the specified graph ID being used in the backing storage. Accommodating this use case could be done with an option for the Federated Store AddGraph operation to include a direct reference to an internal GUID.
Describe the new feature you'd like Graphs are identified by a 'Graph ID', these are used for all store types.
Inside the Store there could be methods to link the ID to a static unique (GUID style) ID. These methods would allow for a graph ID to be changed whilst keeping the GUID the same.
Why do you want this feature? It would make implementing graph IDs changes in future Gaffer Stores much easier.
Stores which make use of a separate system for providing backing storage to store graph data (currently only the Accumulo Store) do not have a standardised approach for how to identify data associated with different graphs. For example, in Accumulo data for a Gaffer graph is stored in an Accumulo table with a table name the same as the Gaffer graph ID. This works so long as the Gaffer graph ID doesn't change. If a graph's ID needs to be changed, this also necessitates a change to the Accumulo table name associated with that graph. With the GUID approach above, the Accumulo table name would always be unique and wouldn't need to be changed - only the mapping from graph ID to GUID would change.
Describe alternatives you've considered Continuing to have ad-hoc management of this in individual stores with custom code in the Federated Store to facilitate graph ID changes.
Additional context See #2495 for context. While the Accumulo Store is used as an example above, it would be breaking to remove the current method.
Re-adding an existing graph (where data already exists) is a use case which relies on the specified graph ID being used in the backing storage. Accommodating this use case could be done with an option for the Federated Store
AddGraphoperation to include a direct reference to an internal GUID.