Hi Tx,
This is just to close the loop. Thank you very much for your helpful
suggestions.
This works fine and solves our problem.
Much appreciated.Clive
From: kiwi clive
To: Trejkaz ; Lucene Users Mailing List
Sent: Wednesday, February 1, 2017 7:37 PM
Subject: Re: How do I write in
From: Trejkaz
To: Lucene Users Mailing List ; kiwi clive
Sent: Wednesday, February 1, 2017 2:53 PM
Subject: Re: How do I write in 3.x format to an upgradeded index using Lucene
4.10
> If we take our old 3.x index and apply IndexUpgrader to it, we end up with a
> 4.10 index.
>
through this rather lengthy explanation
and please let me know if I have not described the issue clearly.
If it's just "Duh, you need to just do this..", I'd be a happy man :-)
Many thanks,
Clive
Hi Guys,
We have an index/query server that contains several thousand fairly hefty
indexes. Each searcher is shared between many 'user-threads' and once opened we
keep the searcher in a cache which is refreshed depending on how often it is
used. Due to memory limitations on the server, we need s
Hi Mike,
Thanks for the very prompt and clear response. We look forward to using the new
(new for us) Lucenene goodies :-)
Clive
From: Michael McCandless
To: Lucene Users ; kiwi clive
Sent: Thursday, May 28, 2015 2:34 AM
Subject: Re: Search Performance with NRT
As long as you
Hi Guys
We are considering changing our Lucene indexer / search architecture from 2
separate JVMs to a single one to benefit from the very latest index views NRT
readers provide.
In the past we cached our IndexSearchers to avoid cold searches every time and
reopened them periodically. In the
Hi Hoss,
Many thanks for the information. This looks very encouraging as the Java7 bug I
remember was fixed and as far as I know, we should not be affected by the
others.
I'll put a few tests together and put my toe in the water :-)
Clive
From: Chris Hostetter
To: "
.
In an ideal world we would have Java8 + lucene4.x reading a lucene3.6 index
(that was created with Java6).
Then we would write to the lucen3.6 index using java8 and lucene4.x.
Any suggestions would be most welcome!
Many thanks,Clive
runs (we have 10,000+ shards). If
it were not for the consolidation required, I thin bobo would have been the way
forward.
I appreciate you taking the time to explain the situation.
Clive
From: Shai Erera
To: "java-user@lucene.apache.org" ; kiw
to reindex.
- use of solr is not an option but a lucene version upgrade is.
Am I right in thinking the implementation of facetting is different in solr to
that in lucene ?
If you could point me a resource so I can learn more, I'd be very grateful.
Many thanks,
Clive
Thank you Mike,
Much appreciated :-)
From: Michael McCandless
To: java-user@lucene.apache.org; kiwi clive
Sent: Monday, March 18, 2013 4:14 PM
Subject: Re: Lucene 4.1 org.apache.lucene.document.Field Deprecation
You need to create your own FieldType, e.g
.
Is there an equivalent of STORED=NO, ANALYZED=YES and
TERMVECTORS_WITH_POSITIONS in the new API?
Apologies if I've missed something, but I don't want to lose this functionality!
Thanks,
Clive
changed
appreciably.
Thanks for any help.
Clive
old
functionality, that could bite you.
There are two solutions that I am aware of:
(1) Replace StandardAnalyzer with ClassicAnalyzer which I believe is the 'old'
StandardAnalayzer before it was fixed.
(2) Use StandardAnalyzer with Version_23 rather than Version_40.
Che
Hi Bin Lan,
This bit me too.
You can choose to StandardAnalyzer and set the version number to 2.9.
Otherwise you can try using ClassicAnalyzer which I belive is 'old' Standard
Analyzer before it was tidied up.
Clive
From: Bin Lan
To:
the top page-size records. This way the ramindex
only has to be small and the database does the heavy lifting. - Although at the
cost of some sql trickery :-)
From: selvakumar netaji
To: java-user@lucene.apache.org; kiwi clive
Sent: Tuesday, November 13
I have used the last solution you mention many times to good effect as you can
sort across the two data sources and merge the results.
Obviously it depends on your architecture, RAM and and the amount of data you
are dealing with.
Clive
From: selvakumar
new
version that I was not previously using, the Ferrari was in first gear and now
we are taking advantage of these features.
This is truly phenominal step-change in throughput, thank you Lucene developers
!
Clive
From: Ian Lea
To: java-user@lucene.apache.
of
documents through the indexer and it seams to work admirably although I would
be happier if the load average came down.
Any lucene devs out there who could shed some light on this behaviour ?
Thanks,
Clive
From: kiwi clive
To: "java-user@lucene.apach
difference.
Clive
From: Lance Norskog
To: java-user@lucene.apache.org; kiwi clive
Sent: Sunday, October 28, 2012 11:09 PM
Subject: Re: A large number of files in an index (3.6)
An option: instead of merging continuously as you run, you can optimize with
index is closed. Thanks for the
advice, I need to revisit the merging section of the application.
Clive
From: Vitaly Funstein
To: java-user@lucene.apache.org
Sent: Friday, October 26, 2012 8:13 PM
Subject: Re: Lucene 3.6.0 Index Size
One thing to keep in
realize this is a large version jump but a doubling in index size does not
seem a step in the right direction to me ;-)
I am using cfs format.
Thanks,
Clive
I did some tests and found for our need, ClassicAnalyzer was better (backwards
compatible). Our analyzer uses different tokenizers on certain fields but (used
to) fall back to StandardAnalyzer by default. ClassicAnalyzer will meet our
needs but I see we should move onto a newer implementation su
rg/apache/lucene/analysis/standard/StandardTokenizer.html
> http://lucene.apache.org/core/4_0_0-BETA/analyzers-common/org/apache/lucene/analysis/standard/ClassicTokenizer.html
>
> -- Jack Krupansky
>
> -Original Message- From: kiwi clive
> Sent: Wednesday, October 24, 2012 6:42 AM
> To:
on for the change and is ClassicAnalyzer now the defacto-analyzer to use ?
Thanks,
Clive
objects.
So if I wanted to search across two different types of document in one index
with some fields on one doc type and some on the other, I effectively need to
perform 4 queries.
This is kind of where I was coming from.
Thanks,
Clive
From:
impl
whilst the trunk (4.0) doesn't have this limitation.
Martijn
On 29 March 2012 14:39, Michael McCandless wrote:
> It'll be in both 3.6 and 4.0.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Thu, Mar 29, 2012 at 7:55 AM, kiwi clive wrote:
> >
Hi Chaps,
JoinUtil.createJoinQuery() specifies a Query for the from side of the join.
Is it possible to query over both sides of the join (while still providing the
two join fields) ? If not, what is the recommended best practice to do this?
Thanks, and apologies for the dumb questions
C
Hi Guys,
Will this be available in Lucene 3.6 or is it only going into version 4.0 ?
Clive
Hello
I've been looking at the BlockJoinQuery in Lucene 3.4.0 and would like to
clarify my understanding.
Suppose we have a parent document that we index with (say) 4 child documents.
My understanding is that these go in as an atomic unit and allows us to query
and join across the documents.
this appears to close the
index without performing the merge. At least that is my understanding of things
!
Clive
- Original Message -
From: Michael McCandless
To: java-user@lucene.apache.org
Cc:
Sent: Tuesday, July 26, 2011 5:30 PM
Subject: Re: Closing IndexWriter can be very slow
Thanks' for the promped reply I will look for something similar for the dot
net version, I posted in this group as it is more active.
--
View this message in context:
http://www.nabble.com/Lucene-Dynamic-http-Web-Page-Search-tf1867987.html#a5111083
Sent from the Lucene - Java Users forum at Nabb
Hi,
I am working on adding a search feature to a web site that uses single
database driven aspx pages and would like to know if Lucene can search using
the http url address or database to index from.
As current I can only see Lucene being able to search physical files in a
windows folder.
Any
33 matches
Mail list logo
