UUIDs are ugly and we do present them to the user (for instance in the route view, although maybe that needs rethinking as well. Nonetheless, we probably don't want UUIDs used as entity IDs in the GTFS export either . . . )
In order to reduce transaction overhead, we can put the atomic long in a separate database with a single global transaction. We wrap that in call that makes a commit in versioned data store, so that an ID is not returned until it has been written to disk. That way, in a crash, the worst thing that can happen is that we skip a few ids - not the end of the world.
UUIDs are ugly and we do present them to the user (for instance in the route view, although maybe that needs rethinking as well. Nonetheless, we probably don't want UUIDs used as entity IDs in the GTFS export either . . . )
In order to reduce transaction overhead, we can put the atomic long in a separate database with a single global transaction. We wrap that in call that makes a commit in versioned data store, so that an ID is not returned until it has been written to disk. That way, in a crash, the worst thing that can happen is that we skip a few ids - not the end of the world.