Hello, > The use case is that our users want to have something like > the find and replace in word, so we have to match any nodes > or proerties in the repository which contains the keyword, > even if it is just part of a word, and then there is a UI > page for the users to choose which one they want to do the > replacement.
For this use case you must use jcr:contains because it will be much less slow. You only might run into some problems regarding lucene stemming and removal op stopwords. Stemming (the process for reducing inflected (or sometimes derived) words to their stem, base or root form) results for example that "stemmer", "stemmed", "stemming" all are reduced to "stem". Now, with jcr:contains if you look for "stemm*" you probably do not get a hit (while for "stemm" you might). With jcr:like you do not have this problem, because these fields are not tokenized, but this directly will result in extreme slow queries (don't be surprised that you see queries for 1000 nodes of > 10 sec for prefix % in jcr:like) Anyhow, I think you have a use case that requires deep knowledge about lucene how to implement this best (perhaps work with an extra index containing n-grams tokens), and also about jackrabbit: what if a user with one click can alter like 50.000 nodes....you'll have some performance issues here -Ard > > Juan > -- > View this message in context: > http://www.nabble.com/does-jcr%3Alike-has-a-wildcard-like-jcr% > 3Acontain--tp15143136p15149174.html > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >
