3 ms·
> As far as I know, no database has ever had any of the problems he mentions with IDs not round-tripping properly during backup/restore. Simple example - neo4j
by yetihehe 8y ago
> As far as I know, no database has ever had any of the problems he mentions with IDs not round-tripping properly during backup/restore.
Simple example - neo4j. Node id's are reused when deleted and you can't create node with id you want. Documentation mentions this. We've just used unique random strings as keys.
- esonderegger 8y agoI suppose it depends on the method used for backup and restore. If you replace the entire graph.db directory with one from a backup, ids are kept intact. I was relying on this just yesterday. We use graphenedb for our production database and I needed to load a production backup locally for testing. It was really useful that I could query a node by id both locally and on prod and get the same result.
- yetihehe 8y agoYeah, for debugging it's ok, but we once had to migrate between versions where we couldn't keep graph.db but had to recreate all nodes and relationships. Relying on id's in production anywhere outside of single transaction is too unreliable.