[elephant-devel] inherited indices

[Vassilis Radis]

On Thu, Apr 28, 2011 at 8:34 PM, Ian Eslick <eslick at media.mit.edu> wrote:

> 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.
>
> 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.
>
> I like this.


> 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 -


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


> 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)
>
> And if I understand correctly again , this deals with Alex's concern,
right?


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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20110429/236bd6b4/attachment.html>