voltaserve
voltaserve copied to clipboard
Optimize data model for PostgreSQL
Description:
Migration plan:
- First we introduce a new SERIAL column on all tables that require one, this will auto-initialize IDs
- Then we swap the existing id column for the serial column. I have to see if a column rename updates the foreign key constraints.
- This would be a rename of both the "id" as well as the foreign columns
- Then we introduce a new foreign key column in dependents, mapping the current IDs to the new SERIAL IDs
- Lastly, we convert the old column with UUID and let PostgreSQL generate these instead of picking up the existing IDs
Apply the hashids on the PK we now create, and utilize UUIDs for exchange formats; that way, for systems that require exchanging data, they can use the UUID to reference things, as they are guaranteed to be unique across installs. Meanwhile, for optimization, the hashids can quickly encode/decode to actual database IDs and make the ID opaque to those that don't need to know about it. So the API still utilizes the hashids in path arguments and json payloads, but they instead map to an "instance unique" DB ID. But for external use, the primary id becomes the UUID identifying the global resource. Which would allow, in the future, instances where a folder could potentially map onto a secondary voltaserve. Or some kind of sync tool that keeps two voltaserve instances in sync by registering an "on change" listener, and exchanges identical files identified by their UUID.