News for hackers. Stuff that matters.
Re:Database IDs Have No Place in URIs (2008) by yetihehe on Friday May 10, 2019 @09:03AM (#19877298)
> 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.

Re:Database IDs Have No Place in URIs (2008) by esonderegger on Friday May 10, 2019 @09:16AM (#19877397)
I 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.

Re:Database IDs Have No Place in URIs (2008) by yetihehe on Friday May 10, 2019 @09:46AM (#19877620)
Yeah, 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.