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

Simon Poole notifications at github.com
Sat Apr 6 15:57:36 UTC 2019

Am 06.04.2019 um 17:32 schrieb mmd:
>     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.
But it is entirely unnecessary except in a chunked upload scenario (aka
the client still has non-uploaded changes that have references to the
uploaded data). The -only- thing that the user/editor needs to know in
the non-chunked scenario is if the upload was successful or not. If
successful there is no need to update the local data after the fact, as
that is only an optimisation (which iD for example does), which can be
replaced by downloading again.
> 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.
All allow one of the three options manually (AFAIK they don't explicitly
offer them though).

> 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.
Chunked uploads are problematic, but that isn't covered by the original
proposal either.
> (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.
Not if the changeset has been uploaded, but if the last upload to the
changeset was successful.
> 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).
IMHO if we want to support chunked downloads, there does actually need
to be a way of accessing the last diffresult data, but a single API call
with the changeset as parameter would be enough as it is trivial for the
client to determine if the changes have already been applied or not :

- diff upload fails for the client

- calls "last diff result" API call

- checks if changes have already been applied, if no -re-uploads- if
yes, applies changes from diff result.


>> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480513276>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AA9wlI1vRVRl2Oyn-vEkH5OLNk8Qfw3uks5veL4XgaJpZM4cgFOf>.

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/b90840e9/attachment.html>

More information about the rails-dev mailing list