[OSM-dev] Grumble, grumble

[Matt Amos]

On Mon, May 11, 2009 at 9:05 AM, Stefan de Konink <stefan at konink.de> wrote:
> On Mon, 11 May 2009, Frederik Ramm wrote:
>
>> Stefan de Konink wrote:
>> > If 0.6 is a transaction based system, the transaction should be stored
>> > server side in a changeset right?
>>
>> I don't think any transaction based system stores aborted transactions?
>
> But is the transaction aborted? If so it could never be resolved :)

the transaction is rolled back if any element in the diff upload
cannot be committed. calling it "aborted" is a bit harsh ;-)

>> > In anycase; I think what should happen is a resultset upon closing of
>> > the changeset that would show you the conflicts.
>>
>> As documented in
>>
>> http://wiki.openstreetmap.org/wiki/0.6#Diff_upload:_POST_.2Fapi.2F0.6.2Fchangeset.2F.23id.2Fupload
>>
>> information about the first conflict only will be returned.
>
> Ok this is *bad*; because I assume this is based upon a failure instead of
> a check. What imho should happen is an active check for the records begin
> inserted and preferably gracefully remove changes that have been applied
> already if they have the same outcome.

well... it fails a check :-P

what you are suggesting is complicated. at the moment the server keeps
it simple by saying "if you're trying to update an element and your
version number doesn't match the most recent, thats a conflict which
you must resolve." this is the same policy as SVN - the server rejects
all conflicts and leaves them to the client (sorry, frederik and
richard ;-) )

it might be possible, however, to catch the error in the diff parsing
routine and continue with the next element of the upload, returning
the error in the diffResult. bearing in mind that the second or later
errors may be caused by previous errors, if this behaviour is
preferable to the client devs then it can be changed.

cheers,

matt