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
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.
The text was updated successfully, but these errors were encountered:
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
AddGraph
operation to include a direct reference to an internal GUID.The text was updated successfully, but these errors were encountered: