Oh, I overlooked the simplest way to do that. You're right, tokens are
the key to this problem. It works pretty well.
It would be perfect if I use payloads. I read your advice
http://www.lucidimagination.com/blog/category/payloads/.
You store the payloads with your PayLoadAnalyzer in this way:
On Sep 17, 2009, at 5:06 AM, Thomas Rewig wrote:
Oh, I overlooked the simplest way to do that. You're right, tokens
are the key to this problem. It works pretty well.
It would be perfect if I use payloads. I read your advice http://www.lucidimagination.com/blog/category/payloads/
.
You stor
Hello ,
I would also prefer to store the content in the index because, as Erick
points out this leads to a more simplified design but also because it allows
me to preserve the relevance sort.
If you store only the item id in the index then when extracting all the
other required data from supp
Hello,
I have tried your method, but it doesn't work.
set will be null after applying
BitSet set = filter.bits(reader);
I haven't found any reason for this.
Additionally, the bits method is deprecated and it is mentioned to use
"getDocIdSet". But this set does only provide an iterator, no hash
Hi all,
Since you can't (and it doesn't make sense to) use wildcards in phrase
queries, how do you construct a query to get results for phrases that
begin with a certain set of terms? Here are some theoretical
examples...
Example 1 - I have an index where each document contains the content
> Since you can't (and it doesn't make sense to) use
> wildcards in phrase
> queries, how do you construct a query to get results for
> phrases that begin with a certain set of terms?
> Here are some theoretical examples...
>
>
> Example 1 - I have an index where each document contains
> the co
: It turns out that the cause of the exceptions is in fact adding an item
: twice - so you were correct right at the start :-) I ran a test where I
glad to see it all worked out.
: Just a minor point: isn't Lucence in a position to detect the duplicate
: insertion attempt and flag it with so
Since you can't (and it doesn't make sense to) use wildcards in phrase
queries,
You can with this:
http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/misc/src/java/org/apache/lucene/queryParser/complexPhrase/
Discussion here: http://tinyurl.com/lrnage
Cheers,
Mark
Assuming i understand you correctly, then...
1. properties only exist as part of a single article (no articles share
a complex property)
2. you don't have any need to ever return searchese on
properties, they exist just to add in searching for articles.
IF that's correct, then the idea i w
FWWI: a test case with multiple asserts is more useful if you clarify
where it failes ... ie: show us the failure message, or put a comment on
athe line of the assert that fails.
i didn't run your testcase, but skimming it a few things jumpt out at me
that might explain whatever problem you ar
10 matches
Mail list logo
