[OSM-dev] Grumble, grumble

[Matt Amos]

On Mon, May 11, 2009 at 1:21 PM, Stefan de Konink <stefan at konink.de> wrote:
> On Mon, 11 May 2009, Matt Amos wrote:
>
>> > 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 ;-)
>
> Then the actual changeset is persistent, even not applied?

the changeset is not affected, and persists, but none of the changes
in the uploaded diff will be in it.

>> >> > 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.
>>
>> 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 ;-) )
>
> That is just bad, because if you go this far, then I suggest the client
> should bbox the changeset in 0.7 by XAPI style (this gets you layers
> aswell) and the bbox/props will not be given out.

i don't understand what you're trying to say. changesets have bboxes,
yes. they're calculated from the data, not exposed in the URI like
XAPI does.

>> 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.
>
> I think you could use the OSM Fixer query style to check the actual
> differences. But might be better to start a different thread on this.

to be honest, i'm with frederik on this - if he wants diffs to be
atomic, if that makes development easier for him, then i think we
should just leave it as it is.

cheers,

matt