Thanks Joel for the quick response. I have opened a new jira ticket.
https://issues.apache.org/jira/browse/SOLR-6168
On 13 June 2014 17:45, Joel Bernstein wrote:
> Let's open a new ticket.
>
> Joel Bernstein
> Search Engineer at Heliosearch
>
>
> On Fri, Jun 13, 2014 at 8:08 AM, Umesh Prasad
Try /products?wt=xml and compare. VRW is just a writer; it doesn't affect the
results in any way. Let's see the rest of those handler definitions -
different query parser is my hunch. Or maybe your velocity template is not
showing the actual results?
Erik
> On Jun 13, 2014, at 22:44, "O.
Hi,
Can you paste your field type definition? Could it be you have acat1 in your
stopwords.txt?
On Saturday, June 14, 2014 7:03 AM, "Tang, Tj" wrote:
I am seeing issues where when I search for ‘ACAT1’ I do not get any results,
but with ‘ACAT’ I get the result, where the exact match is ‘A
I run into the same problem, but a little different. Using SOLR 4.6.0. When I
try to update a couple of fields, all my fields are intact except the text
field that was populated from a PDF file. How do I keep the text there? I
resorted to re-indexing everything, all 1.2 million records. Took foreve
Is this a schema in when the text field is actually populated via
from other fields?
Or maybe not, but the text field may not have been a stored field. It needs
to be one of the two.
-- Jack Krupansky
-Original Message-
From: librarymark
Sent: Saturday, June 14, 2014 10:40 AM
To:
Thank you Erik. I tried /products?q=hp|lync&wt=xml and I show no results i.e.
numFound="0", so I think there is something wrong. You are correct, that the
VRW is not the problem but the Query Parser. Could you please let me know
how to determine the query parser?
For most part I have not changed t
It is a stored field. It is the only one that gets dropped. It is text from a
PDF that is streamed into SOLR.
--
View this message in context:
http://lucene.472066.n3.nabble.com/How-to-update-one-field-without-losing-the-others-tp3989959p4141858.html
Sent from the Solr - User mailing list arch
We are looking to move from legacy master/slave configuration to the cloud
configuration.
In the past we have handled rebuilding cores by using a 'live' core and a core
for performing the rebuild on.
When a rebuild is complete, we swap the rebuilt core with the live core.
Is this still a good w
If you don't need near real-time index freshness, why are you implementing Solr
Cloud? It is harder to set up and adds functionality you are not using. Solr
Cloud is designed for a fully live index, not offline indexing.
Also, I don't understand why people do this complicated offline build and
Thanks Walter -
We have a few different use cases where there is no good way [currently] to
uniquely identify a document.
We also have some cores where real-time freshness is key.
I'd rather move to cloud than have 2 different instances.
Since some cores will need to have all documents deleted d
Exactly. Do one commit at the end. I do this for indexes with 4 million or more
documents. Works fine.
I don't know of a way to flush the queued add-document commands. Solr does not
have the concept of a single transaction that can be dropped.
wunder
On Jun 14, 2014, at 12:57 PM, "Branham, Jer
Perfect.
Rather than rolling back a single transaction, we could just rollback
everything since the last commit.
Thanks for the insight.
Jeremy Branham
-Original Message-
From: Walter Underwood [mailto:wun...@wunderwood.org]
Sent: Saturday, June 14, 2014 3:03 PM
To: solr-user@lucene.a
12 matches
Mail list logo
