<br><br><div class="gmail_quote">On Thu, Apr 28, 2011 at 8:34 PM, Ian Eslick <span dir="ltr"><<a href="mailto:eslick@media.mit.edu">eslick@media.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I agree the semantics of inherited indexing is off.  I implemented what worked for me at the time and was an easy extension to what was already there.  However, the issues around class redefinition, database connection state, schema synchronization, data loss protection, etc make code changes around index management a trickier than you'd think.<br>

<br>
One solution is to get rid of the :inherited option and simply allow a :subclasses? option to get-instances-by-value/range that uses the mop to find subclass indexes and does a merge sort of all objects returned by the various indexes.  This becomes time O(k log_b n) and gets rid of inherited indexing.<br>

<br></blockquote><div>I like this. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
However, if the k is going to matter or you want a faster option, you can keep :inherited (one big index) and have get-instances-by--value/range filter out classes you didn't ask for (i.e if base class get everything, if asking for subclass and inherited then just return matching subclasses -</blockquote>
<div> </div><div>If i understand correctly, Alex suggests that this for some (many?) cases could actually be slow if query returns many unwanted instances for reasons after searching</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
you could even do this before object instantiation to make it extremely efficient by testing the schema ID associated with the OID (checking for older schemas that need to be upgraded if schema upgrading is set to lazy)<br>

<font color="#888888"><br></font></blockquote><div>And if I understand correctly again , this deals with Alex's concern, right?</div><div> </div><div><br></div><div>But I like the first idea better, because it gets rid of indexed inheriting and combines the best of the two worlds: When we want many classes, fetch and read only those we want (and not all the tree and then filter), and when we want one fetch only that one.</div>
<div><br></div><div>Well the first is correct assuming that fetching all the tree and filtering the instances is slower than merge sorting the instances. Any rough estimates on this?</div></div><br><div><br></div>