On Sun, Jun 26, 2011 at 2:01 PM, Shaun McDonald <sh...@shaunmcdonald.me.uk> wrote: >
> If you use the diff uploads, then it is already the case that a changeset > could be called a collection of transactions, though the transaction id is > never exposed or stored. (Technically the transaction ids and status are used > internally for the generation of the diffs). You're right Shaun. Let me clarify a bit. In a hypothetical .07, the transaction IDs would be exposed.This would have two clear benefits. First, it would provide a simple mechanism by which one could "play the events".Each transaction could be played and then run in sequence. Based on a number of users who come to the project this is the "expected behavior". Our current behavior is one that grew out of the project's history, but new developers often get tripped up on what exactly a changeset is, and why it's not atomic. A transaction could be assumed to be atomic, Another benefit of that would be the ability to have asynchronous transactions, which could lead to a better editing experience. An API call could happen quickly, the client could be given a transaction ID and then optionally not need to wait for the transaction to happen before letting the user move on. This isn't something that comes up often, but we do have instances where an upload takes a long time because the database is doing some validation- eg deletion of nodes requires that those nodes be checked against ways and relations which may contain that node, which makes that very expensive. Rejected uploads don't come up often, but because there's no concept of a transaction id to refer to after the call, an editor needs to block while the transaction takes place. If this could be eliminated, then the editing process could be made more smooth. It's a minor benefit, but not insignificant. - Serge > > Shaun > > _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
