[OSM-dev] Auto closing of changesets in API 0.6
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)
> 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
>> to see if it has an open changeset to use, thus preventing open
> It would be good style for an application to remember any changesets
> has opened and try to re-use them; however if it crashes and loses
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2433 bytes
Desc: not available
More information about the dev