<div class="gmail_quote">On Thu, Jan 29, 2009 at 1:06 AM, Matt Amos <span dir="ltr"><<a href="mailto:zerebubuth@gmail.com">zerebubuth@gmail.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">On 1/28/09, Brett Henderson <<a href="mailto:brett@bretth.com">brett@bretth.com</a>> wrote:<br>
> Is the bounding box info updated within the same transaction as entity<br>
> updates or can it be updated asynchronously with a separate daemon?  I<br>
> remember discussions about bbox updates only occurring occasionally (ie.<br>
> the bbox is made slightly larger than necessary to avoid large numbers<br>
> of writes) but I'm fairly sure they're updated synchronous at the same<br>
> time as the entity causing the update, at least I hope so.<br>
<br>
</div>bounding box info is updated in the same transaction as the entity. as<br>
you say, the bbox is over-expanded to avoid having to write each time.<br>
but, because of the restrictions on the member count, the changeset<br>
ends up needing to be updated every time anyway, rendering the<br>
previous optimisation pointless :-)<br>
<br>
the existing implementation is deliberately naive, which could hurt<br>
the performance of diff uploads, but there is scope for optimisation<br>
later on without changing the API.<br>
</blockquote><div><br>Can someone remind me again please.  What's the purpose of calculating and storing the bbox for each changeset?<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;">
<br>
cheers,<br>
<font color="#888888"><br>
matt<br>
</font></blockquote></div><br>