[OSM-dev] Auto closing of changesets in API 0.6

Shaun McDonald shaun at shaunmcdonald.me.uk
Fri Oct 3 16:28:07 BST 2008


On 3 Oct 2008, at 15:54, Frederik Ramm wrote:

> (forgot to reply to list)
>
> Hi,
>
> Shaun McDonald wrote:
>> Should changesets automatically be closed after a period of time?  
>> If so
>> how long?
>
> I thought that when a changeset is created and whenever something is
> added, the expiration date is set to "now + 30 minutes". A changeset
> whose expiration date is in the past is considered closed. That would
> have the advantage of not having to run a cleanup job.
>
> (On second reading, I thing the idea was a little bit cleverer: If you
> add something to a changeset *and* the expiration date is within the
> next 30 minutes, add 60 minutes. This would mean less updates to the
> changeset table.)

There is a slight issue here, because in the database table for  
changesets only stores the time it was created_at (timestamp), and  
whether it is open, as a boolea. It doesn't store the expiry time, nor  
the time it was closed.

>
>
>> Are changesets useful if they are never closed, or empty?
>
> With that logic, a never-closed changeset would not happen (unless
> someone tries really hard!). An empty changeset is useless I believe.
>

Should we have a daemon to clear empty expired changesets?

>> Should there be a way for an application to be able to query and  
>> check
>> to see if it has an open changeset to use, thus preventing open  
>> changesets?
>
> It would be good style for an application to remember any changesets  
> it
> has opened and try to re-use them; however if it crashes and loses  
> track
> of a changeset that would not hurt since the changeset would
> automatically "expire".

I was specifically thinking of the case when the app might crash.

Shaun

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081003/c8286609/attachment.bin>


More information about the dev mailing list