Hi,
I just moved from 1.9.1 to 2.1-dev. One error that seems to happen a lot now
is below. I haven't had the chance to investigate yet (note the time), but I
thought I'd throw (no pun intended) it out there and see if anyone else has
seen this before.
java.lang.NoSuchFieldError: prohibited
Personally, I think of it as not a 'not' operator, but more a 'but not'
or 'and not' operator. Thats not totally the case I believe, but gives
you semantics that work. Truly I think that each part of the query
creates a score and the NOT query scores 0. That gives a different
result than a bool
: This example only works with lucene Version 1.4.3, because when I use lucene
: Version 2, then I get the error message:
: The selected method Keyword was not found
You can find info about this in the FAQ...
http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-d09fdfc8a6335eab4e3f3dc8ac41a40a366
Hello,
I don't understand how to use "not" with Lucene. I
think that it is not a boolean not. I read the
documentation but it is not clear enough on how the
"not" works.
For example, I tried to do this request:
type:product
--> I got 100 responses. It is normal. Then, I tried
this request:
type:p
Hello,
first of all I'm totally new to lucene.
I've found this article:
http://coldfusion.sys-con.com/read/42053.htm?CFID=608986
http://coldfusion.sys-con.com/read/42053.htm?CFID=608986&;
CFTOKEN=126FE5E6-9ACC-1407-B3D2BE2FEB9396C4>
&CFTOKEN=126FE5E6-9ACC-1407-B3D2BE2FEB9396C4
AND this is ver
Hi,
Just noticed this thread and don't know if this has been mentioned. What
I do is add a 'path' field with the xpath to the node. Then you first
narrow your search by finding documents with paths like:
/node[1]/node[3]*
best,
-Rob
karl wettin wrote:
25 nov 2006 kl. 17.12 skrev Chris Hos
25 nov 2006 kl. 17.12 skrev Chris Hostetter:
personally ... i'd rather have a slightly bigger index then slightly
slower queries.
Me too, usually. But I'm running this in my alternative RAM index, so
it should be OK. That is also the reason to why I want to save thoses
bytes. But again, t
: There is however virtually no cost for me to calculate the full path,
: so I might just experiment with the span query thingy.
if you odn't mind using a span, then just reverse the ordering so the
"leaf" that the docs are at appear in the first position -- then you can
use a SpanFirst to check