[OSM-dev] Minute Diffs Broken

[Matt Amos]

On Tue, May 5, 2009 at 11:38 AM, Frederik Ramm <frederik at remote.org> wrote:
> Hi,
>
> Tom Hughes wrote:
>>> Of course there's always the possibility to simply drop the
>>> transaction around the diff upload. I don't think many people actually
>>> *rely* on it, but it was one of the features we thought were nice to
>>> have...
>>
>> Er no there isn't. That is absolutely positively definitely not going to
>> happen.
>>
>> Do that and we're back exactly where we started - send a change (or set
>> of changes in this case which is worse) to the API and have it fail and
>> be left with a partial change applied.
>
> The main problem with 0.5 was that it sometimes applied changes to
> current without applying them to history (or was it the other way
> round). This is now solved and nobody is suggesting to go back.
>
> But being able to make a bunch of edits and process them in one
> transaction is new with 0.6 and not something that users actually
> demanded to have - it is something we thought could come in handy.

doesn't it make the client coding much simpler to have an
all-or-nothing upload action? that was the assumption that i was
working under - if its wrong we can figure something else out. for
example, it would be quite simple to send back a partial diffResult
document which indicated which element failed (and the error message)
and which elements are still to upload.

> As
> for JOSM, I have already heard complaints, and people have asked how
> they can go back to the old non-changeset upload, because they
> explicitly *want* as much as possible of their changeset to upload, and
> are pissed off when the whole changeset fails because it contains a
> change to some monster object that is changed very often.

can JOSM split the single upload into multiple uploads within the same
changeset? perhaps having a tunable parameter to isolate "large" items
into their own separate upload?

there is no reason why one save = one upload = one changeset.

and this will help with the problem that Brett is seeing, which
might(*) be down to the following:

1. user on a slow connection hits "save", changeset created, client
begins diff upload
2. server starts transaction
3. client sends first element, which the server parses and saves
4. ... client and/or network slowness cause 5 mins to pass ...
5. client ends the diff
6. server ends the transaction

because we're assigning timestamps in rails (at step 3), but the rows
only become visible at step 6, the delay between the end of the
transaction and the timestamp on the element could be up to 24h, in
theory.

cheers,

matt

*: certainly this is possible with rails+fastcgi, but i'm not sure
whether it actually happens on the real server.