<div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 7, 2012 at 5:22 PM, Toby Murray <span dir="ltr"><<a href="mailto:toby.murray@gmail.com" target="_blank">toby.murray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Nov 7, 2012 at 10:15 AM, Matt Amos <<a href="mailto:zerebubuth@gmail.com">zerebubuth@gmail.com</a>> wrote:<br>
> On Fri, Nov 2, 2012 at 6:34 AM, Toby Murray <<a href="mailto:toby.murray@gmail.com">toby.murray@gmail.com</a>> wrote:<br>
>><br>
</div><div class="im">>> It looks like changesets don't show up until they are closed. This<br>
>> makes sense since then you don't have to worry about information<br>
>> changing.<br>
><br>
><br>
> hmm... this shouldn't be the case - changesets should show up when they're<br>
> opened and again when they're closed. if they're opened and closed in the<br>
> same period, it will only show the closed state. this seems to be what<br>
> happens with most changesets - they open and close within a few seconds.<br>
<br>
</div>I looked at 5 consecutive diffs just now and there was not a single<br>
open changeset. Other random ones I've looked at in the past also<br>
don't have any open ones. I find this highly unlikely since it is<br>
actually kind of hard to manually close a changeset in P2. So I<br>
suspect you have a bug. Possibly the same bug that affected the weekly<br>
planet dump until a few weeks ago when I noticed it and Tom fixed it:<br></blockquote><div><br></div><div>ah... just noticed a massive bug - i was assigning both created_at and closed_at from the database's created_at! no wonder it thought everything was already closed. right, i'll go fix that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://git.openstreetmap.org/planetdump.git/commitdiff/e406711139b9eb8db9d32fa4094325ec3841082c?hp=beb331bcdf6e5565b02fcccce61be397c150bc03" target="_blank">http://git.openstreetmap.org/planetdump.git/commitdiff/e406711139b9eb8db9d32fa4094325ec3841082c?hp=beb331bcdf6e5565b02fcccce61be397c150bc03</a><br>

<br>
The problem was that all changesets have the closed_at field set to<br>
one hour in the future whenever the changeset is touched. This is<br>
stored in UTC. If one hour has passed since the last change, meaning<br>
that closed_at is in the past, the changeset is considered closed. But<br>
the SQL that determines the changeset's openness uses the now()<br>
function which by default returns server local time. During daylight<br>
savings time in London this means that, the "closed_at > now()" check<br>
always returned false so all changesets were marked as being closed in<br>
the weekly dump.<br>
<br>
But then again, DST is no longer in effect... So it may be something else.</blockquote><div><br></div><div>yeah, i thought i handled that - all calls in the code are UTC, although i see i've used now() in one SQL statement, but it's just to get a starting list and is filtered against the correct time later in the code.</div>
<div><br></div><div>i will have to do some investigation...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>><br>
>> However, what will it do in the edge case where a changeset is closed<br>
>> but then reopened? Not possible you say? I once had an upload take<br>
>> over an hour to process. It did eventually succeed but the changeset<br>
>> was marked as closed in my changeset list for several minutes before<br>
>> the upload finished and then it was suddenly open again. I am assuming<br>
>> in this case the changeset would show up twice in the minutely diffs<br>
>> and cause the INSERT queries of all consumers to explode violently :)<br>
><br>
><br>
> yeah... i don't think the code is able to handle this at the moment... maybe<br>
> it would see the re-opening, but probably not. any specific examples of this<br>
> would be great, btw, to help me start building up some test cases.<br>
<br>
</div>Ok well if the changeset normally shows up twice in the feed anyway<br>
then tools will need to handle this so it shouldn't be a problem on<br>
the consumer side. But yes, the code generating the diffs does need to<br>
take this into account. I know the osmosis diffs are based on database<br>
transactions so they pick up any row that has changed since the last<br>
diff. Applied to changesets, this would actually produce an entry in<br>
the stream every time a chunk was uploaded (in JOSM chunked upload<br>
mode)<br></blockquote><div><br></div><div>yeah, i wanted to avoid the changeset being in the feed too many times (e.g: chunked upload). ideally only when it is opened and closed, although there are situations where it probably prints out more often.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By examples, do you mean a changeset ID? Since this is all time based<br>
that won't do much good since now the changeset will look like any<br>
other changeset that I held open for 2 hours.</blockquote><div><br></div><div>i'll have to find more inventive ways to test the code, then ;-)</div><div><br></div><div>cheers,</div><div><br></div><div>matt</div><div>
<br></div></div></div>