purpose or use of the pos/len. But I'm sure that your observation WRT
them not being used in the final XPath step is correct.
But I can unequivocally state that your understanding of indexed searches is correct.
There is no optimization. It's not terribly efficient (nothing like you would get
using the query engine of a modern RDBMS). And, the XPath is applied at the
end to each selected document (to produce the subset of the document
specified for selection by the XPath). If you are selecting entire documents,
the final XPath step is a complete waste -- it is not needed (but there is no
way to turn it off). Would be nice to have a query that would select whole
documents containing matches for the specified XPath.
-Terry
jcplerm wrote:
Do Xindice indices keep a pointer to the location of a value ([EMAIL PROTECTED], for instance) inside stored resources, or just the keys for the documents they appear in?Looking at the source code, Indexer method "add" has the following signature:public void add(String value, Key key, int pos, int len, short elemID, short attrID);Do "pos" and "len" refer to the place the "value" appears inside a stored resource identified by "key"?Looking at another piece of code, method "XPathQueryResolver.prepareNextNode()", it seems that when the query is being executed and resources being fetched from the database, the "keys" are only relevant to the point of fetching documents from the database. Once a resource is loaded into a DBDocument object, the XPath is "re-executed" entirely on this DBDocument.This then leads me to the conclusion that indices are only useful to the extent of locating the keys for documents in the database, but from that point on, the fetched documents must be searched with xpath anyway, without any help from "pos/len" information.This question is not critical, but would help me better understand how Xindice works.If anyone can shed some light, I would appreciate.Thanks,jlerm
