On 11 Oct 2008, at 15:53, Frederik Ramm wrote: > Hi, > > Shaun McDonald wrote: >> Alternatively if we state that a changeset is private until it is >> closed, and has a limited life, then you could simply calculate the >> bbox on closing of the changeset. > > Yes but the original plan was based on the idea that changesets do > not require an explicit close, they have an implicit close (if their > validity expires). The elegance of that is *not* requiring a huge > clean-up deamon that closes changesets and computes bounding boxes > and dies every now and then ;-) >
If the consensus is to store the closing time of the changeset, then I will update the migrations and other code as required. Determining whether or not a changeset is closed, would be determined by whether the closing_timestamp is less than the current time. Is this comparison significantly slower than checking a boolean? You would still be able to close a changeset manually as the api would set the closing_timestamp to Time.now. >> One problem we have at the moment, is that the changeset determines >> the after state. You can assume that changeset.version-1 is the >> previous version. However I'm sure we're not meant to assume that a >> new version=old_version+1. > > You might change the same object twice within the same changeset, > then the changeset would have old_version=new_version-2... True. However what I say still applies for the first change of that object. You wouldn't be able to use the last change of the object (if there are multiple) to determine the prior version, as someone else may have made an edit in between, or you have edited that object in between in another editor, thus that edit went into a different changeset. Shaun _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
