<div class="gmail_quote">On Wed, Jan 28, 2009 at 1:06 PM, Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com">brett@bretth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">80n wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
    Replication of changesets is on my undocumented long term TODO<br>
    list for<br>
    osmosis (I should add it to trac) but I don't know when I'll be<br>
    able to<br>
    do it.  I had some discussions with Shaun and Matt a while back on how<br>
    this might be done efficiently.  Identifying changesets for<br>
    replication<br>
    is a bit tricky and would probably involve two passes, first pass<br>
    would<br>
    identify all changesets created in a time interval, and the second<br>
    pass<br>
    would identify all changesets modified (ie. have entities referring to<br>
    them) in a time interval.  Once identified they could be read and<br>
    included in a changeset file just like any other entity.<br>
<br>
<br>
Perhaps you only need to worry about exporting the changeset headers.  The members of a changeset can be derived from the elements themselves.<br>
</blockquote></div>
Yes, that is fine, in fact I think that's what we were planning to do ... my memory is hazy :-)  The header info is the difficult bit because it changes over time.  From memory (I don't have the schema handy) the main issue is the bounding box fields.  These can be updated over time as new entity updates are added to the changeset.  I agree that only the header info needs to be extracted, but it needs to be included in every changeset that has an entity referring to it in case the bounding box was updated since the last replication.<br>

<br>
Is the bounding box info updated within the same transaction as entity updates or can it be updated asynchronously with a separate daemon?  I remember discussions about bbox updates only occurring occasionally (ie. the bbox is made slightly larger than necessary to avoid large numbers of writes) but I'm fairly sure they're updated synchronous at the same time as the entity causing the update, at least I hope so.<br>
<font color="#888888">
</font></blockquote><div><br>The bbox can also be derived from the changeset members so that's not really essential either.  The rest of the header probably won't change significantly, if at all, during the life of a changeset.<br>
<br>I think you could just query the api directly, the changeset ids will be allocated sequentially.  As changesets are automatically closed after 24 hours, a second query process running 24 hours behind can re-query each changeset and be sure that it will no longer change.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
Brett<br>
<br>
</font></blockquote></div><br>