a quick glance at the code seems to indicate that MultiSearcher has code
for calcuating the docFreq accross all of the Searchables when searching
(or when the docFreq method is explicitly called) but that explain method
just delegates to Searchable that the specific docid came from.
if you com
Bleh, never mind this, I've replied to the wrong thread... mea culpa.
On Dec 7, 2007 4:21 PM, Tom Emerson <[EMAIL PROTECTED]> wrote:
> Hi Mark,
>
> Thanks for the pointer, but for my application I already have a custom
> query parser, and I think the use of a functional query will do what I want.
Hi Mark,
Thanks for the pointer, but for my application I already have a custom query
parser, and I think the use of a functional query will do what I want.
-tree
On Jun 28, 2007 7:46 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> You might try my Query Parser, Qsol. http://myhardshadow.com/q
Hi Grant,
I was thinking that something in o.a.l.search.function was going to be the
route to take, but wanted to hear if there were other ideas from the
experts. Thanks!
A custom sort wouldn't work in this case because we don't want the items to
necessarily be bunched together, rather just have
smokey <[EMAIL PROTECTED]> wrote on 04/12/2007 16:54:32:
> Thanks for the information on o.a.l.search.spans.
>
> I was thinking of parsing the phrase query string into a
> sequence of terms,
> then constructing a phrase query object using add(Term term,
> int position)
> method in org.apache.lucen
Have a look at the o.a.l.search.function package, which can be used to
give boosts to documents based on the value contained in a field.
Also, would a custom sort work?
-Grant
On Dec 7, 2007, at 1:42 PM, Tom Emerson wrote:
Hello,
I'm looking for suggestions on how to deal with the follow
Erik,
Thanks for the response. The issue with
(original query) AND (field:foo^boost1 OR field:bar^boost2 OR
field:baz^boost3)
means that the 'field' must have a value for the query to succeed, which
isn't always the case: there could be documents where 'field' has no value.
So unless I understan
It seems like doing something like pre-processing the query
(or equivlently, adding a BooleanClause to a BooleanQuery)
that expressed
(your original query) AND (field:foo^boost1 OR field:bar^boost2 OR
field:baz^boost3)
should do the trick. Or I'm just not understanding what you're doing at all
Eri
Thanks for the reply Erik. However, my follow up question is this:
What about the block of code that appears in the startElement() method:
if(atts.getLength()>0){
attributeMap=new HashMap();
Do we need to modify it at all in anyway? Your suggestion works, but isn't
this redundant?
Hello,
I'm looking for suggestions on how to deal with the following (simplified)
scenario (Lucene 2.2.0):
Documents in my index have some number of fields that are searched in
various combinations via boolean queries.
Each document also contains a field that contains a field that isn't
searched
Thanks for your reply. I am aware of the new API, but with the new API that
you provided we lost the ability to "Store" the field as a string (the
Value), but "Tokenize" it differently for Indexing, using a Reader.
Matthijs Bierman wrote:
>
> Hi,
>
> I would recommend downloading the 1.9.0 rel
I was thinking that you'd assemble a BooleanQuery, perhaps with phrase
queries, perhaps not. The critical thing here is to add in a BooleanClause
that included your filter on the relevant field (s).
Erick
On Dec 7, 2007 9:57 AM, d33mb33 <[EMAIL PROTECTED]> wrote:
>
>
> Erick Erickson wrote:
> >
Erick Erickson wrote:
>
> Have you looked at Filters? Essentially, you construct a bitmap where each
> bit corresponds to a document and pass that along into your search.
> Constructing a filter is surprisingly speedy.
>
Thanks for the reply.. I'll take a look at filters.
So in my "Charles Di
Have you looked at Filters? Essentially, you construct a bitmap where each
bit corresponds to a document and pass that along into your search.
Constructing
a filter is surprisingly speedy.
What you lose is relevancy for the filtered part of the query. See
ConstantScoreQuery.
Also, search the mail
There are active discussions now on java-dev about trying to get the
2.3 release out "soon", maybe in the next month or two.
However, nothing is certain!
Best to check java-dev and follow along...
Mike
Ivan Vasilev wrote:
Hi Lucene Guys,
Can you say approximately when will be released L
Hi,
I would recommend downloading the 1.9.0 release for porting your code.
It will show you what's deprecated and the javadoc will show you the
proper way to do it.
What you would want with your field is:
/** Constructs a String-valued Field that is tokenized and indexed,
and is stored in
Hi Lucene Guys,
Can you say approximately when will be released Lucene 2.3? We have some
costumizations in the source code of hte Lucene and we will have to
transfer them in the 2.3 release, so it is important for us to know when
approximately this will happen in order to make our plans.
Tha
I have developed a fuzzy search application over a database of books (titles,
authors etc) and it works really well. (I use Lucene.Net but read the
JavaDocs and forums for java Lucene)
However I've got an interesting use case with "TooManyClauses" and need some
help in solving it.
My users acce
Fayyaz - that is the incorrect action to take. That will cause
future documents to have fields from all previous ones! All you
have to do is:
private HashMap attributeMap = new HashMap();
Erik
On Dec 6, 2007, at 9:53 PM, syedfa wrote:
Thanks very much for your reply. I co
On Dec 6, 2007, at 9:02 PM, 游泳池的鱼 wrote:
Hi, it's my first time to use lucene maillist. I have problem that
when I
add a document with IndexWriter , it searchable for the IndexSearcher
instance which is creat before the document flush to index? if
lucene can
not do this,any suggest to sol
20 matches
Mail list logo
