[OSM-dev] Grumble, grumble

Stefan de Konink stefan at konink.de
Mon May 11 13:21:18 BST 2009


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?

> >> > 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

Don't go grammar on me :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 ;-) )

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.

> 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.


Stefan





More information about the dev mailing list