[openstreetmap/openstreetmap-website] Idempotency for API 0.6 (#2201)

Tom Hughes notifications at github.com
Thu Apr 18 07:59:13 UTC 2019


Storing 800k objects that have a short lifetime is just not what relational databases are designed for. Well I mean acting as a cache in general is not really what they are designed for...

I mean this whole thing is insane anyway but that's just the icing on the cake.

Look I could probably live with the idea of the idempotency key (there are better solutions I think but nobody seems to want to listen to that) but the idea of just straight up caching the actual raw HTTP response is just batshit insane.

The trouble of course is that we can't rebuild the response from the database in response to repeated requests because we don't know which bits of the changeset relate to which upload :-(

The only solutions to that are to limit changesets to a single upload, or to introduce an extra level of object underneath the changeset but that means a massive database update to tie objects to the "upload" id rather the changeset id.

Sadly it seems everybody in this thread is would rather slap any old nonsense together in the aim of rolling it out yesterday rather than coming up with a sane solution that might actually take time to implement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-484396809
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20190418/0e8fb601/attachment.html>


More information about the rails-dev mailing list