[KinoSearch] more abstract interfaces to kinosearch
Hans Dieter Pearcey
hdp at pobox.com
Thu Jun 21 05:53:49 PDT 2007
On Wed, Jun 20, 2007 at 09:05:58PM -0700, Marvin Humphrey wrote:
>
> On Jun 20, 2007, at 8:09 PM, Hans Dieter Pearcey wrote:
>
> >* easier adding/loading: $index->add(@objects), or perhaps $index-
> >>load()
> > (using a predefined, per-schema data source)
>
> I'm can see those statements meaning several different things. Can
> you please elaborate on what it is you're trying to do?
That's because they do mean different things, but I was too tired when I was
writing that email to see how confusing it was.
Right now I have a base index manager class. That base class has a structure
for handling new input; that's where the $index->add(@objects) example came
from. Subclasses have a to_doc() method that they override. The whole thing
is not much more than a convenient wrapper around a combination of open/clobber
and for (@objects) { $inv->add_doc }
I also have a subclass that knows where its data comes from. It keeps track of
the last-indexed document from that data source and can create/update
invindexes based on various parameters (e.g. userid => 17). This means I don't
actually have to pass it any objects at all; I can just say $index->update
periodically and it takes care of finding new things to index and indexing
them.
That part hasn't been properly abstracted yet. It's very specific to that
particular subclass and data source (and indexing schema), and it's also not
very polished, so I'm not sure how it will turn out yet; in particular, if I'm
generating multiple indexes from a single data source, the last update kind of
metadat needs to be shared between them, they need to all be updated with a
single pull of data instead of each looking for updates, etc.
hdp.
More information about the kinosearch
mailing list