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

mmd notifications at github.com
Sat Apr 6 15:32:38 UTC 2019

> I have to say from an editor POV there is no good solution as invariably the link between template ids in the editor and what has actually been created in the DB is lost.

...unless the _diffResult_ reponse is important enough to store it one the database for later retrieval, and associate it to some kind of unique identifier provided by the client.

I have to say that I don't find any of the 3 options you mentioned compelling, and that's the main motivation for opening up this issue. JOSM implements option 1, iD either 1 and/or 3 (not exactly sure at the moment), maybe some other editor does 2 already.

Allowing only a single upload per changeset sounds tempting, but it doesn't solve the diffResult issue,. and many users would very likely be somewhat unhappy with this approach.

Let's assume someone wants to upload 12'000 changes, first upload w/ 10'000 changes runs, changeset gets closed, yet the diffResult gets lost due to some networking issue on the way back.
How would you match the actual object ids to the placeholder ids in this case? This information may be crucial for the remaining 2'000 objects, if they have references to those 10'000 objects.

(By the way, 10'000 is just the maximum changeset size I used an an example. If a user has configured their JOSM to upload data in chunks of eg. 500 objects, this very same situation can obviously occur with much smaller changesets).

Using some kind of changeset counter would allow some heuristic to find out if a changeset has been uploaded. Like in the previous case, it doesn't solve the diffResult issue. Implementation wise you would have to
* extend the changeset table, 
* extend the changeset API call,
* change the changeset upload to update the counter,
* issue a separate changeset query call on the client after a failed changeset
* download the changeset
* implement some heuristic to match actual object ids back to placeholder ids (unless no more data is to be uploaded, in which case you can simply re-download the area in question, like iD does).

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20190406/b3031a8d/attachment.html>

More information about the rails-dev mailing list