[elephant-devel] inherited indices

[Ian Eslick]

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.

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

Ian

On Apr 28, 2011, at 9:31 AM, Alex Mizrahi wrote:

>> Why? I am by no means an expert and never looked thoroughly the code,
>> but ,abstractly speaking, doesnt it boil down to just creating
>> more indexes automatically at class definition time?
> 
> Code assumes that there is only one index it needs to update at time, so it 
> needs to be revised to handle many of them.
> Nothing particularly hard, but it requires some code rewriting and thus
> 
> While another alternative is pretty much trivial.
> 
>> Independently of the whole subject, I think this should be done anyway,
>> and it can be an optional param with a default for old behaviour for those 
>> who want the whole pie.
>> I think many people subtypep the results of get-instance family funcs 
>> early in their projects.
> 
> I don't think that 'old behaviour' was intentional, people should not depend 
> on query for one sub-class returning instances of another sub-class.
> And it is trivial to fix it -- just pass super-class instead of sub-class to 
> this function if you want all instances.
> 
> So I think get-instances-by-... should unconditionally do the filtering.
> 
> While map-inverted-index probably shouldn't do the filtering. I consider it 
> a lower-level API which works with index directly, without a promise to 
> return instances of certain class.
> And also implementing it at that level is somewhat harder. 
> 
> 
> 
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel