[elephant-devel] inherited indices

[Vassilis Radis]

On Thu, Apr 28, 2011 at 7:31 PM, Alex Mizrahi <killerstorm at newmail.ru>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.


You are right then.


>

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.
>
> Totally agree with that. From the index point of view, class hierarchy
relationships are irrelevant and even non existent, since at that level the
only distinguishable relationship is the key-value one. It would be wrong to
inject such semantics at that level.


>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20110429/aef73fff/attachment.html>