Facet counts and drill down queries
Hi all, I have a question about facet counts and drill down queries. When I run a drill down query, I only get counts for the category in the query, but I need the counts for all categories. Is there a way to do this without running two separate searches? I'm using a MultiCollector to wrap a TopDocsCollector and FacetsCollector. Thanks for your help! Tobi
Re: lucene-core-3.3.0 not optimizing
Hi I have used Index and Optimize 5+ Million XML docs in Lucene 1.x7 years ago, And this piece of IndexWriter.optimize used to Merger all the bits and pieces of the created into 1 big file. I have not tracked the API changes since 7 yearsand with lucene-core-3.3.0 ...on google not able to find the solutions Why this is happening. with regards karthik On Fri, Dec 2, 2011 at 12:37 PM, Simon Willnauer < simon.willna...@googlemail.com> wrote: > what do you understand when you say optimize? Unless you tell us what > this code does in your case and what you'd expect it doing its > impossible to give you any reasonable answer. > > simon > > On Fri, Dec 2, 2011 at 4:54 AM, KARTHIK SHIVAKUMAR > wrote: > > Hi > > > > Spec > > O/s win os 7 > > Jdk : 1.6.0_29 > > Lucene lucene-core-3.3.0 > > > > > > > > Finally after Indexing successfully ,Why this Code does not optimize ( > > sample code ) > > > >INDEX_WRITER.optimize(100); > >INDEX_WRITER.commit(); > >INDEX_WRITER.close(); > > > > > > *N.S.KARTHIK > > R.M.S.COLONY > > BEHIND BANK OF INDIA > > R.M.V 2ND STAGE > > BANGALORE > > 560094* > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > -- *N.S.KARTHIK R.M.S.COLONY BEHIND BANK OF INDIA R.M.V 2ND STAGE BANGALORE 560094*
Re: lucene-core-3.3.0 not optimizing
Well, calling optimize(maxNumSegments) will (from the javadocs on recent releases) "Optimize the index down to <= maxNumSegments". So optimize(100) won't get you down to 1 big file, unless you are using compound files perhaps. Maybe it did something different 7 years ago but that seems very unlikely. In 3.5.0 all optimize() calls are deprecated anyway. I suggest you read the release notes and the javadocs, upgrade to 3.5.0 and remove all optimize() calls altogether. -- Ian. On Fri, Dec 2, 2011 at 9:58 AM, KARTHIK SHIVAKUMAR wrote: > Hi > > I have used Index and Optimize 5+ Million XML docs in Lucene 1.x 7 > years ago, > > And this piece of IndexWriter.optimize used to Merger all the bits and > pieces of the created into 1 big file. > > I have not tracked the API changes since 7 yearsand with > lucene-core-3.3.0 ...on google not able to find the solutions Why this is > happening. > > > with regards > karthik > > On Fri, Dec 2, 2011 at 12:37 PM, Simon Willnauer < > simon.willna...@googlemail.com> wrote: > >> what do you understand when you say optimize? Unless you tell us what >> this code does in your case and what you'd expect it doing its >> impossible to give you any reasonable answer. >> >> simon >> >> On Fri, Dec 2, 2011 at 4:54 AM, KARTHIK SHIVAKUMAR >> wrote: >> > Hi >> > >> > Spec >> > O/s win os 7 >> > Jdk : 1.6.0_29 >> > Lucene lucene-core-3.3.0 >> > >> > >> > >> > Finally after Indexing successfully ,Why this Code does not optimize ( >> > sample code ) >> > >> > INDEX_WRITER.optimize(100); >> > INDEX_WRITER.commit(); >> > INDEX_WRITER.close(); >> > >> > >> > *N.S.KARTHIK >> > R.M.S.COLONY >> > BEHIND BANK OF INDIA >> > R.M.V 2ND STAGE >> > BANGALORE >> > 560094* >> >> - >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> > > > -- > *N.S.KARTHIK > R.M.S.COLONY > BEHIND BANK OF INDIA > R.M.V 2ND STAGE > BANGALORE > 560094* - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: lucene-core-3.3.0 not optimizing
On 02.12.2011, at 04:54, KARTHIK SHIVAKUMAR wrote: > Hi > > Spec > O/s win os 7 > Jdk : 1.6.0_29 > Lucene lucene-core-3.3.0 > > Finally after Indexing successfully ,Why this Code does not optimize ( > sample code ) > >INDEX_WRITER.optimize(100); >INDEX_WRITER.commit(); >INDEX_WRITER.close(); Because you shouldn't use it [1] in general. :-) Simon [1‘ https://issues.apache.org/jira/browse/LUCENE-3454 - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
Re: Lucene index inside of a web app?
What would the web.xml look like? I'm lost.
On Thu, Dec 1, 2011 at 11:04 PM, KARTHIK SHIVAKUMAR
wrote:
> Hi
>
> >> generated Lucene index
>
> What if u need to upgrade this with More docs
>
> Best approach is Inject the Real path of the Index ( c:/temp/Indexes ) to
> the Web server Application via "web.xml"
>
> By this approach u can even achieve
>
> 1) Load balancing of multiple Web servers pointing to same Index files
> 2) Update /Delete /Re-index with out the Web application being interrupted
>
>
>
> with regards
> Karthik
>
> On Tue, Nov 29, 2011 at 12:25 AM, okayndc wrote:
>
> > Awesome. Thanks guys!
> >
> > On Mon, Nov 28, 2011 at 12:19 PM, Uwe Schindler wrote:
> >
> > > You can store the index in WEB_INF directory, just use something:
> > > ServletContext.getRealPath("/WEB-INF/data/myIndexName");
> > >
> > > -
> > > Uwe Schindler
> > > H.-H.-Meier-Allee 63, D-28213 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > >
> > > > -Original Message-
> > > > From: Ian Lea [mailto:ian@gmail.com]
> > > > Sent: Monday, November 28, 2011 6:11 PM
> > > > To: java-user@lucene.apache.org
> > > > Subject: Re: Lucene index inside of a web app?
> > > >
> > > > Using a static string is fine - it just wasn't clear from your
> original
> > > post what it
> > > > was.
> > > >
> > > > I usually use a full path read from a properties file so that I can
> > > change
> > > it
> > > > without a recompile, have different settings on test/live/whatever
> > > systems, etc.
> > > > Works for me, but isn't the only way to do it.
> > > >
> > > > If you know where your app lives, you could use a full path pointing
> to
> > > > somewhere within that tree, or you could use a partial path that the
> > app
> > > server
> > > > will interpret relative to something. Which is fine too - take your
> > pick
> > > of
> > > > whatever works for you.
> > > >
> > > >
> > > > --
> > > > Ian.
> > > >
> > > >
> > > > On Mon, Nov 28, 2011 at 4:40 PM, okayndc
> wrote:
> > > > > Hi,
> > > > >
> > > > > Thanks for your response. Yes, LUCENE_INDEX_DIRECTORY is a static
> > > > > string which contains the file system path of the index (for
> example,
> > > > c:\\index).
> > > > > Is this good practice? If not, what should the full path to an
> > > > > index look like?
> > > > >
> > > > > Thanks
> > > > >
> > > > > On Mon, Nov 28, 2011 at 4:54 AM, Ian Lea
> wrote:
> > > > >
> > > > >> What is LUCENE_INDEX_DIRECTORY? Some static string in your app?
> > > > >>
> > > > >> Lucene knows nothing about your app, JSP, or what app server you
> are
> > > > >> using. It requires a file system path and it is up to you to
> > provide
> > > > >> that. I always use a full path since I prefer to store indexes
> > > > >> outside the app and it avoids complications with what the app
> server
> > > > >> considers the default directory. But if you want to store it
> inside,
> > > > >> without specifying full path, look at the docs for your app
> server.
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Ian.
> > > > >>
> > > > >>
> > > > >> On Sun, Nov 27, 2011 at 2:10 AM, okayndc
> > wrote:
> > > > >> > Hello,
> > > > >> >
> > > > >> > I want to store the generated Lucene index inside of my Java
> > > > >> > application, preferably within a folder where my JSP files are
> > > > >> > located. I also want
> > > > >> to
> > > > >> > be able to search from the index within the web app. I've been
> > > > >> > using the LUCENE_INDEX_DIRECTORY but, this is on a file system
> > > > >> > (currently my hard drive). Should I continue to use
> > > > >> > LUCENE_INDEX_DIRECTORY if I want the Lucene index inside the app
> > or
> > > > >> > use something else. I was a bit confused about this. Btw, the
> > > Lucene index
> > > > content comes from a database.
> > > > >> >
> > > > >> > Any help is appreciated
> > > > >> >
> > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> > > > >> For additional commands, e-mail: java-user-h...@lucene.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: java-user-h...@lucene.apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: java-user-h...@lucene.apache.org
> > >
> > >
> >
>
>
>
> --
> *N.S.KARTHIK
> R.M.S.COLONY
> BEHIND BANK OF INDIA
> R.M.V 2ND STAGE
> BANGALORE
> 560094*
>
Re: Facet counts and drill down queries
Hi Tobi, What is the facet request that you define for the drill down query? I.e., if your initial query was 'foo' and you asked to count facet ABC. Then the user clicks one of he categories of facet ABC (that's your drill down query) -- what is the facet the you ask to count for the drill down query? If I misunderstood your question, do you have a small test case that shows the problem, or can write some mock up code, that explains it? Shai On Friday, December 2, 2011, Tobias Knaup wrote: > Hi all, > > I have a question about facet counts and drill down queries. > When I run a drill down query, I only get counts for the category in the > query, but I need the counts for all categories. > Is there a way to do this without running two separate searches? > I'm using a MultiCollector to wrap a TopDocsCollector and FacetsCollector. > > Thanks for your help! > > Tobi >
Re: Facet counts and drill down queries
Hi Shai, Thanks for your response. Here is some example code that illustrates the problem: https://gist.github.com/1424333 Thanks Tobi On Fri, Dec 2, 2011 at 8:31 AM, Shai Erera wrote: > Hi Tobi, > > What is the facet request that you define for the drill down query? I.e., > if your initial query was 'foo' and you asked to count facet ABC. Then the > user clicks one of he categories of facet ABC (that's your drill down > query) -- what is the facet the you ask to count for the drill down query? > > If I misunderstood your question, do you have a small test case that shows > the problem, or can write some mock up code, that explains it? > > Shai > > On Friday, December 2, 2011, Tobias Knaup wrote: > > Hi all, > > > > I have a question about facet counts and drill down queries. > > When I run a drill down query, I only get counts for the category in the > > query, but I need the counts for all categories. > > Is there a way to do this without running two separate searches? > > I'm using a MultiCollector to wrap a TopDocsCollector and > FacetsCollector. > > > > Thanks for your help! > > > > Tobi > > >
IndexReader.openIfChanged Doesn't Work on MultiReader
Just checking if this is a known issue or if I should report it. I have a MultiReader made up of 3 different indexes. If changes are made to either of the 3 underlying indexes, isCurrent() returns false (correctly) on said MultiReader. However, if I use the method IndexReader.openIfChanged() on the MultiReader, a new MultiReader is returned (it does NOT return null), but its isCurrent() method is still reporting false. Also, a search using this new MultiReader doesn't not see the index changes (deletes and additions). I have to explicitly close the MultiReader and open it again to see changes, but the documentation states this is an inefficient way of refreshing readers. I assumed someone must have run into this before? Jordon - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
RE: IndexReader.openIfChanged Doesn't Work on MultiReader
Hi, > I have a MultiReader made up of 3 different indexes. If changes are made to > either of the 3 underlying indexes, isCurrent() returns false (correctly) on said > MultiReader. However, if I use the method IndexReader.openIfChanged() on > the MultiReader, a new MultiReader is returned (it does NOT return null), but > its isCurrent() method is still reporting false. Also, a search using this new > MultiReader doesn't not see the index changes (deletes and additions). I have > to explicitly close the MultiReader and open it again to see changes, but the > documentation states this is an inefficient way of refreshing readers. It is not inefficient as MultiReader is just a light wrapper around a collection of readers. If you simply openIfChanged (!) each subreader yourself and wrap them by a new MultiReader it will not slowdown anything. MultiReader.doOpenIfChanged does nothing else, but maybe with a bug introduced by the refactoring. > I assumed someone must have run into this before? Can you open an issue at https://issues.apache.org/jira/browse/LUCENE ? Uwe - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
