Andy Armstrong wrote:
> My current approach is to have a one-to-one relationship between Xindice > documents and Lucene's concept of a document but it's just occured > to me that I should maybe have a Lucene document for each chunk > of text in a Xindice document.
One may want to implement a full text index on several different index patterns. e.g. specify an index on some element and an index on some attribute, Would your implementation handle that case?
Just out of curiosity, does your implementation support the existing standard XPath approach to searching? What sort of analyzer are you using? Did you decide to allow users to specify the analyzer somehow?
Great to see you continuing work on this! Thanks.
-Terry
Andy Armstrong wrote:
Vadim Gritsenko wrote:
Andy Armstrong wrote:
I'm currently working on integrating full text indexing and searching and as part of that I need to extend the o.a.x.c.i.Indexer interface to include
public void startDocument(Key key) throws DBException; public void endDocument(Key key) throws DBException;
Can you explain a bit why these methods are needed, and why existing Indexer interface is not enough?
I'm assuming (perhaps incorrectly) that Indexer.add() can be called more than once for each document which doesn't sit happily with Lucene's API.
My current approach is to have a one-to-one relationship between Xindice documents and Lucene's concept of a document but it's just occured to me that I should maybe have a Lucene document for each chunk of text in a Xindice document.
Sorry; I seem to be thinking out loud now. Let me go and experiment a little.
