Hi,
Great discussion! I've recently started looking at ways to implement the
"search collection" stuff Alex referred to, and it would be great if
this discussion could end up helping design such an implementation. We
should move to dev@ for the details.
On 29/11/10 14:21, Ard Schrijvers wrote:
For example mandatad behaviour according spec:
//*...@jcr:contains(.,'jcr')]
must return *all* nodes in the current workspace that contain jcr.
This effectively mandates that the entire thing can be searched as a
'single' index.
By the spec the above query could just as well be implemented by a tree
traversal, just like the SQL standard makes no demands on where and how
RDBMs uses indexes.
What I'd like to see is an equivalent of the CREATE INDEX statement that
could be used to add JCR indexes that selectively boost the performance
of the kinds of searches that a specific deployment is relying on.
PS. Regarding index-in-JCR, nowadays with a file-based data store a
Lucene search index stored and accessed as JCR nodes and properties
should be pretty efficient...
BR,
Jukka Zitting
