We use integers for account IDs, order IDs, and authz IDs. This makes sense because at the database layer they're all just auto-increment integers.
We also sometimes use strings for authzIDs. We did this because we thought we were being forward-thinking about a future when everything would be in a key-value store and we'd be generating random strings for IDs in boulder, rather than relying on database auto-increment.
However, that future has not materialized, and we no longer think we're headed that direction in the near-term future. We should convert all uses of string authzIDs into integer authzIDs.
This will likely be a multi-sided change:
- Add int-types fields to all gRPC messages that use strings for authzIDs. Change all code which creates such messages to populate both fields. Change all code which consumes such messages to read both fields, preferring the int field if it exists. Wait one whole deploy cycle.
- Drop the string-type fields from all gRPC messages that use strings for authzIDs. Change all code which creates such messages to stop populating the deleted field. Change all code which consumes such messages to stop reading the deleted field. Wait one whole deploy cycle.
- Rename the new int-type field to have the same name as the old string-type field used to have.
We use integers for account IDs, order IDs, and authz IDs. This makes sense because at the database layer they're all just auto-increment integers.
We also sometimes use strings for authzIDs. We did this because we thought we were being forward-thinking about a future when everything would be in a key-value store and we'd be generating random strings for IDs in boulder, rather than relying on database auto-increment.
However, that future has not materialized, and we no longer think we're headed that direction in the near-term future. We should convert all uses of string authzIDs into integer authzIDs.
This will likely be a multi-sided change: