The facets translation should be done at the application level. So if you
index the dimension A w/ two facets A/A1 and A/A2, where A1 should also be
translated to B1 and A2 translated to B2, there are several options:
Index the dimensions A and B with their respective facets, and count the
relevan
Hi,
I'm currently implementing the lucene facets in the version 4.8.1 and
two questions remain for me:
1. Is the an easy way to have translations for the facets? If we use
e.g. the books example, the user should see the translation. But if he
clicks on a link the english value should be used
re is a way to
> iterate on lucene search result (IndexReader) without specify the TopDocs
> number. I want all documents matching the query.
>
> notes:
>
> thanks
>
> Rider
-
To unsubscribe, e-mail: java-
Hi Guys,
I'm using lucene 4.2.1 and I would like to know if there is a way to
iterate on lucene search result (IndexReader) without specify the TopDocs
number. I want all documents matching the query.
notes:
thanks
Rider
The general recommendation is to run the query again but you are right
that it isn't always the correct answer in all circumstances. If you
want to guard against the scenario you outline, do it the way you
suggest, That's fine. In your fluid environment how do you cope when
doc #11 is no longer
Hi
I last used dotLucene 143 and now I'm wanting to upgrade to 294.
What I've discovered is that there are quite a few changes..
One of them is in respect of Search. Previously one supplied a query and
received a number of hits. I didn't have an issue with preservation of state
so was quite happ
The I think what you're looking for is getting the ScoreDoc[] stored in the
TopDocs object. Then modify each doc's score (a ScoreDoc has a doc ID and
score [float]) and then sort the array. You can use Arrays.sort(ScoreDoc[],
Comparator) by passing a Comparator which will compare the doc
hey after the query returned top N docs
then rearrange them with my algortim
--- On Wed, 7/22/09, Shai Erera wrote:
From: Shai Erera
Subject: Re: reranking Lucene TopDocs
To: java-user@lucene.apache.org
Date: Wednesday, July 22, 2009, 6:57 AM
You mean after the query has returned the top N
henok sahilu wrote:
> i like to write a code that re assign weight to documets so that they can
> be reranked
>
> --- On Wed, 7/22/09, Shai Erera wrote:
>
> From: Shai Erera
> Subject: Re: reranking Lucene TopDocs
> To: java-user@lucene.apache.org
> Date: Wednesday, July
i like to write a code that re assign weight to documets so that they can be
reranked
--- On Wed, 7/22/09, Shai Erera wrote:
From: Shai Erera
Subject: Re: reranking Lucene TopDocs
To: java-user@lucene.apache.org
Date: Wednesday, July 22, 2009, 6:44 AM
Can you be more specific? What do you
Can you be more specific? What do you mean by re-rank? Reverse the sort?
give different weights?
Shai
On Wed, Jul 22, 2009 at 4:35 PM, henok sahilu wrote:
> hello there
> i like to re-rank lucene TopDoc result set.
> where shall i start
> thanks
>
>
>
>
>
hello there
i like to re-rank lucene TopDoc result set.
where shall i start
thanks
On Jun 11, 2009, at 1:49 AM, Ian Lea wrote:
This thread seems to be veering well away from your original
straightforward question on how to convert your straighforward code.
So what? It's about Lucene and hence on-topic. Why do you care?
If you want or need these advanced solutions, fine,
This thread seems to be veering well away from your original
straightforward question on how to convert your straighforward code.
If you want or need these advanced solutions, fine, but if your
existing code was fast enough the modified versions suggested earlier
are probably fast enough too.
--
I
On Jun 10, 2009, at 5:02 PM, Yonik Seeley wrote:
On Wed, Jun 10, 2009 at 7:58 PM, Daniel Noll wrote:
It's a shame we don't have an inverted kind of HitCollector where we
can say "give me the next hit", so that we can get the best of both
worlds (like what StAX gives us in the XML world.)
You
On Wed, Jun 10, 2009 at 7:58 PM, Daniel Noll wrote:
> It's a shame we don't have an inverted kind of HitCollector where we
> can say "give me the next hit", so that we can get the best of both
> worlds (like what StAX gives us in the XML world.)
You can get a scorer and call next() yourself.
-Yo
s). Hits and TopDocs are intended for paged results lists.
As a relevant note, what I have noticed about using HitCollector alone
is that the code effectively loses control of the loop (you get the
same problem with any API where you hand it a callback and let it do
all the work, e.g. SAX.) The callbac
On Jun 10, 2009, at 10:49 AM, Uwe Schindler wrote:
To optimize, store the filename not as stored field, but as a non-
tokenized,
indexed term.
How do you do that?
- Paul
-
To unsubscribe, e-mail: java-user-unsubscr...@lucen
hetaphi.de
> -Original Message-
> From: Paul J. Lucas [mailto:p...@lucasmail.org]
> Sent: Wednesday, June 10, 2009 5:26 PM
> To: java-user@lucene.apache.org
> Subject: Re: Migrating from Hit/Hits to TopDocs/TopDocCollector
>
> On Jun 10, 2009, at 3:17 AM, Uwe Schindler wrote:
>
On Jun 10, 2009, at 3:17 AM, Uwe Schindler wrote:
A HitCollector is the correct way to do this (especially because the
order of hits is mostly not interesting when retrieving all hits).
OK, here's what I came up with:
Term t = /* ... */
Collection files = new LinkedList();
FieldS
nt to retrieve all hits, this is
ineffective. A HitCollector is the correct way to do this (especially
because the order of hits is mostly not interesting when retrieving all
hits). Hits and TopDocs are intended for paged results lists.
> Anyway, it's just an example to give a direction..
Same
sage-
>> From: Wouter Heijke [mailto:whei...@xs4all.nl]
>> Sent: Wednesday, June 10, 2009 11:44 AM
>> To: java-user@lucene.apache.org
>> Subject: Re: Migrating from Hit/Hits to TopDocs/TopDocCollector
>>
>>
>> Will this do?
>>
>> IndexReader
e 10, 2009 11:44 AM
> To: java-user@lucene.apache.org
> Subject: Re: Migrating from Hit/Hits to TopDocs/TopDocCollector
>
>
> Will this do?
>
> IndexReader indexReader = searcher.getIndexReader();
> TopDocs topDocs = searcher.search(Query query, int n);
> for (int i =
Will this do?
IndexReader indexReader = searcher.getIndexReader();
TopDocs topDocs = searcher.search(Query query, int n);
for (int i = 0; i < topDocs.scoreDocs.length; i++) {
Document document = indexReader.document( topDocs.scoreDocs[i].doc);
final File f = new File( document.get( &q
// "FILE" is the field that recorded the original file indexed
> final File f = new File( hit.get( "FILE" ) );
> // ...
> }
>
> It's not clear to me how to rewrite the code using TopDocs/TopDocCollector
>
e original file indexed
final File f = new File( hit.get( "FILE" ) );
// ...
}
It's not clear to me how to rewrite the code using TopDocs/
TopDocCollector and how to iterate over the results.
A litt
a of ALL
> the docs in the index, but when you need just top of them HitCollector is
> said to be a performance killer. Then is better to use Hits with the old API
> and TopDocs with current one.
>
> Ivan
>
> AlexElba wrote:
>>
>> Why you don't extend
Hi Alex,
As I know HitColector is useful when you need to deal with some data of
ALL the docs in the index, but when you need just top of them
HitCollector is said to be a performance killer. Then is better to use
Hits with the old API and TopDocs with current one.
Ivan
AlexElba wrote
Why you don't extend to HitCollector and put all logic you need into it?
Ivan Vasilev-2 wrote:
>
> Hi All,
>
> As Hits class was deprecated in current Lucene and is expected to be
> excluded from Lucene 3.0 we decided to change our code so that to use
> TopDocs cl
OK Guys Thanks ,
Thanks for your help. I really think that paging without caching will be
best for in case. I think in most cases users find results in the first
page. When not, I think they would not not go through more than 2-3 more
pages or just will narrow the search by adding more filter
rt the entire set of documents. Which
means to get, say, page 3 in some sort order, somewhere, sometime
you must keep track of the scores for documents 1-200 in order to
insure that docs 201-300 are really in the proper place. Since a
TopDocs is just an int/float pair we're not talking about much me
Hi Ivan,
We had this discussion some time ago on this list, too. I explained another
guy a possibility for TopDocs caching. Just search in the list archives!
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Mess
Hi All,
As Hits class was deprecated in current Lucene and is expected to be
excluded from Lucene 3.0 we decided to change our code so that to use
TopDocs class.
Our app provides paging and now we are uondering what is the bset way to
do it with th TopDocs. I can see only this possibility:
1
It might be faster to use FieldCache.DEFAULT.getStrings(reader,
"empid"), assuming empid is indexed but is not analyzed (or always
analyzes to one token).
Though, that then persists the resulting array in the FieldCache.
We are wanting to create "column stride fields" (LUCENE-1231) to make
Thanks-
Yes in my use-case there are never any deleted documents when the search
is run- (deletion takes place in a pre-processing stage)
Toke Eskildsen wrote on 12/17/2008 08:16:31 AM:
> On Mon, 2008-12-08 at 15:17 +0100, Donna L Gresh wrote:
> > public Vector getIndexIds() throws Exce
On Mon, 2008-12-08 at 15:17 +0100, Donna L Gresh wrote:
> public Vector getIndexIds() throws Exception {
>
> Vector vec = new Vector();
> IndexReader ireader = IndexReader.open(directoryName);
> int numdocs = ireader.numDocs();
>
I'm a great fan of not changing working code for a "might be
better sometime in the far future if lots of things change" ...
Erick
On Mon, Dec 8, 2008 at 10:54 AM, Donna L Gresh <[EMAIL PROTECTED]> wrote:
> Erick-
> Thanks for the pointer; in my app the difference is between 30
> milliseconds an
Erick-
Thanks for the pointer; in my app the difference is between 30
milliseconds and 45 milliseconds (and this is a once-a-day kind of thing),
but hey it's always worth doing something the better way in case my index
ever gets a whole lot bigger or the use case changes-- thanks.
Donna L. Gres
return vec;
>}
>
> Donna L. Gresh
> Business Analytics and Mathematical Sciences
> IBM T.J. Watson Research Center
> (914) 945-2472
> http://www.research.ibm.com/people/g/donnagresh
> [EMAIL PROTECTED]
>
>
> "Ian Vink" <[EMAIL PROT
quot;Ian Vink" <[EMAIL PROTECTED]> wrote on 12/05/2008 05:57:20 PM:
> Is there an easy way to get all the documents in the index?
> Kinda like this:
>
> TopDocs everything = ???.GetAllDocuments();
See the MatchAllDocsQuery in the search package.
-Grant
On Dec 5, 2008, at 5:57 PM, Ian Vink wrote:
Is there an easy way to get all the documents in the index?
Kinda like this:
TopDocs everything = ???.GetAllDocuments();
--
Grant Ingersoll
Lucene Helpful Hints
Is there an easy way to get all the documents in the index?
Kinda like this:
TopDocs everything = ???.GetAllDocuments();
searcher.doc(scoreDoc.doc);
On Thu, Dec 4, 2008 at 6:59 PM, Ian Vink <[EMAIL PROTECTED]> wrote:
> I have this search which returns TopDocs
> TopDocs topDocs = searcher.Search(query, bookFilter, maxDocsToFind);
>
>
> How do I get the document object for the ScoreDoc?
&
I have this search which returns TopDocs
TopDocs topDocs = searcher.Search(query, bookFilter, maxDocsToFind);
How do I get the document object for the ScoreDoc?
foreach (ScoreDoc scoreDoc in topDocs.scoreDocs)
{
??Document myDoc = GetTheDocument(scoreDoc.doc); ??
}
D]>wrote:
>
> Hey there,
> I am having some memory trouble with my Lucene app. I need to get the info
> and delete about 1000 docs every time I execute the app. I get the IDs of
> the documents to delete from a database and for all single ID I get the
> data
> from the index
Hey there,
I am having some memory trouble with my Lucene app. I need to get the info
and delete about 1000 docs every time I execute the app. I get the IDs of
the documents to delete from a database and for all single ID I get the data
from the indexed doc using an index searcher and topdocs
Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
>
> - Original Message
>> From: Cam Bazz <[EMAIL PROTECTED]>
>> To: java-user@lucene.apache.org
>> Sent: Monday, September 15, 2008 11:25:39 PM
>> Subject: Re: TopDocs
ent: Monday, September 15, 2008 11:25:39 PM
> Subject: Re: TopDocs question
>
> Yes, I looked into implementing a custom collector that would return
> number of hits, but - I could not.
>
> collect() can not access anything that is final, and final can not be
> incremented.
Yes, I looked into implementing a custom collector that would return
number of hits, but - I could not.
collect() can not access anything that is final, and final can not be
incremented.
Any ideas?
Best.
On Tue, Sep 16, 2008 at 6:05 AM, Daniel Noll <[EMAIL PROTECTED]> wrote:
> Cam Bazz wrote:
>
Cam Bazz wrote:
Hello,
Could it harm if I make a
searcher.search(query, Integer.MAX_VALUE) ?
I just need to make a query to get the number of hits in this case,
but I dont know what the max hits will be.
PriorityQueue will attempt to allocate an array of that size.
But if you only need to k
Hello,
Could it harm if I make a
searcher.search(query, Integer.MAX_VALUE) ?
I just need to make a query to get the number of hits in this case,
but I dont know what the max hits will be.
Also When I make a topdocs.totalHits is that same as topdocs.scoreDocs.length()?
Best.
-C.A.
---
ext:
http://www.nabble.com/hitcollector-topdocs-tp16275287p16275287.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
View this message in context:
http://www.nabble.com/hitcollector-topdocs-tp16275287p16275287.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional com
53 matches
Mail list logo
