Re:Unexpected downsides of UUID keys in PostgreSQL
by ramchip on Thursday June 22, 2023 @09:29AM
(#36431862)
You can use the DB for this as well, just make a table e.g. "requests" with two columns, the user and the request token. Old entries can be purged on a cron job.
If you add a column to store params as well then you can also do better validation:
> Responding when a customer changes request parameters on a subsequent call where the client request ID stays the same
> We design our APIs to allow our customers to explicitly state their intent. Take the situation where we receive a unique client request token that we have seen before, but there is a parameter combination that is different from the earlier request. We find that it is safest to assume that the customer intended a different outcome, and that this might not be the same request. In response to this situation, we return a validation error indicating a parameter mismatch between idempotent requests. To support this deep validation, we also store the parameters used to make the initial request along with the client request identifier.
Re:Unexpected downsides of UUID keys in PostgreSQL
by jongjong on Thursday June 22, 2023 @10:10AM
(#36432443)
You can but you add an additional database lookup step which will cost you more in performance (and latency) than just using UUIDs as the ID directly with a single table.
Re:Unexpected downsides of UUID keys in PostgreSQL
by ramchip on Thursday June 22, 2023 @05:53PM
(#36439592)
It's only at creation time. When you lookup the record after that you can use the ID directly, and then you don't hit the locality problems from the article.
If you add a column to store params as well then you can also do better validation:
> Responding when a customer changes request parameters on a subsequent call where the client request ID stays the same
> We design our APIs to allow our customers to explicitly state their intent. Take the situation where we receive a unique client request token that we have seen before, but there is a parameter combination that is different from the earlier request. We find that it is safest to assume that the customer intended a different outcome, and that this might not be the same request. In response to this situation, we return a validation error indicating a parameter mismatch between idempotent requests. To support this deep validation, we also store the parameters used to make the initial request along with the client request identifier.
https://aws.amazon.com/builders-library/making-retries-safe-...