At least on service restart, the configured graph should be checked for changes.
Any changes on the graph in service-config do not apply once the named graph already exists.
One has to delete the graph in ArangoDB first, and then restart the service.
While renaming an edge and its collection can be a bigger migration problem, adding new edges for newly added entities should be no problem and a valid use-case.
Tip: Instead of a deep comparison between all configs against the graph, I recommend to generate a hash of the configs and either store this hash in Redis, or as a suffix to the graph name. Once the hash doesn't match, the graph gets instantly deleted and recreated. It's a seamless migration, unless names of existing edges have changed.
At least on service restart, the configured graph should be checked for changes.
Any changes on the graph in service-config do not apply once the named graph already exists.
One has to delete the graph in ArangoDB first, and then restart the service.
While renaming an edge and its collection can be a bigger migration problem, adding new edges for newly added entities should be no problem and a valid use-case.
Tip: Instead of a deep comparison between all configs against the graph, I recommend to generate a hash of the configs and either store this hash in Redis, or as a suffix to the graph name. Once the hash doesn't match, the graph gets instantly deleted and recreated. It's a seamless migration, unless names of existing edges have changed.