On Mon, May 11, 2009 at 1:21 PM, Stefan de Konink <[email protected]> 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
