[OSM-dev] What should the changeset api do?

[Shaun McDonald]

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