Or stop including those files. They were an option in the old admin UI
that 'had' to be propogated through to the new one. But does anyone
actually use them?
Upayavira
On Tue, Dec 18, 2012, at 07:19 AM, Shawn Heisey wrote:
> On 12/17/2012 11:55 PM, Alexandre Rafalovitch wrote:
> > Again, thinking
This is not a definitive answer, but what you are retrieving is the
stored versions of those fields. When the document is indexed, it will
also store the multi-valued values of that field. I see no reason why at
index time it should re-order them - it just writes them to the index in
the order they
The new UI interface does use them (at least some of them) and puts them
into their own section. Unfortunately, the CSS reset does something funny
to their styles (e.g. H1 looks like plain text). But they are used.
Regards,
Alex.
Personal blog: http://blog.outerthoughts.com/
LinkedIn: http://w
Hello
I am making a multi-select facet. For size options it's working fine by
using tag/exclude like this;
..&fq={!tag=dt}size:medium&facet.field{!ex=dt}size
It will return facet counts for all sizes, but filter results on medium
size.
Doing it the same way with the price range facet queries does
Hello,
I have a really simple question i think:
What is the order of the fields that are in the SOLR response?
In SOLR 3.1 it was alfabetic but in SOLR 4 it isn't anymore. Is it
configurable?
I want to know this because i have test script that checks differences in
output between the SOLR versio
thank you for quick response :)
I also have the same observation and I too believe that there is no reason
for Solr to reorder a multi value field.
But would you stay firm on your conclusion if I say that my multi value
field was indexed?
Please note - as per my one year experience with Solr, it
The new UI includes them as ways to customise the interface merely
because they were there in the old one.
I'm questioning whether anyone actually creates/edits those files to
customise their own admin UI, or whether that is a superfluous piece of
functionality that causes more problems (exception
I build a solr version from the solr-4x branch yesterday and so far am
unable to replicate the problems i had before.
I am cautiously optimistic that the problem has been resolved. If i run
into any more problems, I'll let you all know.
--
Med venlig hilsen / Best regards
*John Nielsen*
Progra
Hi,
I've deleted a document using http://localhost:8983/solr/update?stream.body=
skills_s:Perl and the committed the delete
also. Again if search using q=perl i'm able to see the same document but if
i search using q=skills_s:Perl it is not returning any results. Can someone
explain is this how de
Hello!
It seems that Tomcat can't see the the jar's with DataImportHandler.
Did you try adding a tag to your solrconfig.xml, ie.: something
like this:
And putting the apache-solr-dataimporthandler-3.6.1.jar and
apache-solr-dataimporthandler-extras-3.6.1.jar to /usr/share/solr/lib
?
--
Regar
Surely you are deleting documents that have the term Perl in the
skills_s field, but are leaving behind another document that has Perl in
the default field (usually 'text'). Before doing the delete, do 'q=Perl
skills_s:Perl' and see if you get more than one document.
That's what it looks like anyh
Make sure that your curl command includes:
-H "Content-Type: text/xml"
For example,
curl http://localhost:8983/solr/update?commit=true -H "Content-Type:
text/xml" --data-binary '
id:doc-2012-12-18'
-- Jack Krupansky
-Original Message-
From: Dixline
Sent: Tuesday, December 18, 201
Yay, someone actually using it...
Are you using 4.0? In 4.0 it has been merged into a single
UpdateRequestHandler now. As I understand it, if you post XML to
http://localhost:8983/solr/update and provide a tr parameter, it will do
the same thing as the XsltUpdateRequestHandler did.
Upayavira
On
Oh, and since the field name suggests that the field type is "string", be
sure that you have the case exact - string fields are case sensitive.
So, change:
skills_s:Perl
to
skills_s:perl
-- Jack Krupansky
-Original Message-
From: Jack Krupansky
Sent: Tuesday, December 18, 20
> Are you using 4.0? In 4.0 it has been merged into a single
Sorry, forgot to specify Solr version --I am working with 4.0
>As I understand it, if you post XML tohttp://localhost:8983/solr/update and
>provide a tr parameter, it will do
> the same thing as the XsltUpdateRequestHandler did.
Still
Hi,
If you are not in a rush, I'd wait for Solr 4.1. Not that Solr 4.0 is not
usable, but Solr 4.1 will have a ton of fixes.
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm/index.html
Search Analytics - http://sematext.com/search-analytics/index.html
On Tue, Dec 18, 2012 at 2:4
On Tue, Dec 18, 2012 at 4:58 AM, roySolr wrote:
> Hello,
>
> I have a really simple question i think:
>
> What is the order of the fields that are in the SOLR response?
> In SOLR 3.1 it was alfabetic but in SOLR 4 it isn't anymore. Is it
> configurable?
>
> I want to know this because i have test
I don't know of an "official" guarantee of maintaining order but it's
definitely guaranteed an relied upon to retain order. Many will scream if this
changed.
Indexed doesn't matter here because what you get back are the stored values no
matter if the field is indexed or not.
Erik
On De
I finally understand what you meant and called UpdateRequestHandler as
shown below.
curl "http://localhost:8983/solr/w5/update?commit=true&tr=x.xsl
However, I am now getting an error '500 - Unable to initialize
Templates' error. Part of error stack is below. I am not quite
familiar with Solr erro
On 12/18/2012 2:58 AM, roySolr wrote:
What is the order of the fields that are in the SOLR response?
In SOLR 3.1 it was alfabetic but in SOLR 4 it isn't anymore. Is it
configurable?
I want to know this because i have test script that checks differences in
output between the SOLR versions.
When t
Any idea about when Solr 4.1 will be released?
2012/12/18 Otis Gospodnetic
> Hi,
>
> If you are not in a rush, I'd wait for Solr 4.1. Not that Solr 4.0 is not
> usable, but Solr 4.1 will have a ton of fixes.
>
> Otis
> --
> SOLR Performance Monitoring - http://sematext.com/spm/index.html
> Sear
On 12/18/2012 4:57 AM, Upayavira wrote:
The new UI includes them as ways to customise the interface merely
because they were there in the old one.
I'm questioning whether anyone actually creates/edits those files to
customise their own admin UI, or whether that is a superfluous piece of
function
If there is no "official" guarantee in the Javadoc for the code then there
is no official guarantee. Period. If somebody wants an official, contractual
guarantee, a Jira should be filed to do so. To put it simple, are the values
a "list" or a "set"?
-- Jack Krupansky
-Original Message
Never use text/xml, always application/xml.
wunder
On Dec 18, 2012, at 6:03 AM, Jack Krupansky wrote:
> Make sure that your curl command includes:
>
> -H "Content-Type: text/xml"
>
> For example,
>
> curl http://localhost:8983/solr/update?commit=true -H "Content-Type:
> text/xml" --data-bina
I would say such a guarantee is implied by the javadoc to
Analyzer#getPositionIncrementGap . It says this value is an "increment" to be
"added to the next token emitted from tokenStream."
http://lucene.apache.org/core/4_0_0-ALPHA/core/org/apache/lucene/analysis/Analyzer.html#getPositionIncremen
Ah, good points, but only for the INDEXED data, not the STORED data! I
believe the concern is the stored values that are returned from a query.
Although the question does also apply to how a span query would work for a
multi-valued field.
-- Jack Krupansky
-Original Message-
From: Dy
Yes, text/xml is deprecated. But it is less typing for curl commands!
Why Solr doesn't default to application/xml is a mystery.
-- Jack Krupansky
-Original Message-
From: Walter Underwood
Sent: Tuesday, December 18, 2012 10:47 AM
To: solr-user@lucene.apache.org
Subject: Re: Delete by
Got it. Thanks again for all the info! Will open a JIRA and follow up about
this sometime soon.
Thanks,
Nalini
On Fri, Dec 14, 2012 at 1:32 PM, Dyer, James
wrote:
> Nalini,
>
> I don't think you can change the *default* response format until a new
> major release (so its ok for Trunk/5.0 but no
I suppose using this same logic you can not guarantee the tokens on a stored,
single-value field would be stored in the order they arrive either, can you? A
multi-valued field is the same as a single-valued field with the positions
artifically incremented, so what's the difference?
James Dyer
If I connect jconsole to a remote Solr installation (or any app) using
jmx, all the graphs are populated except 'threads' ... is this expected,
or have I done something wrong? I can't seem to locate the answer with
google.
Thanks,
Shawn
"A multi-valued field is the same as a single-valued field with the
positions artifically incremented"
Yes, for the INDEX. But the concept of Lucene-level "positions" is not
relevant to STORED values.
I'm not sure why you are confusing the two.
A single string has guaranteed order of the cha
I agree with you the documentation should be more explicit. I just don't want
to give new users the impression that stored fields won't return in the order
they are added. This is the behavior and I think a lot of us rely on that
today.
James Dyer
E-Commerce Systems
Ingram Content Group
(615)
I'm going to be building a Solr cluster and I want to have a rolling set of
slices so that I can keep a fixed number of days in my collection. If I
send an update to a particular slice leader, will it always hash the unique
key and (probably) forward the doc to another leader?
Thank you,
Scott
Yeah, and this is why I want it to be explicit.
-- Jack Krupansky
-Original Message-
From: Dyer, James
Sent: Tuesday, December 18, 2012 1:54 PM
To: solr-user@lucene.apache.org
Subject: RE: "order" question on solr multi value field
I agree with you the documentation should be more exp
On Tue, Dec 18, 2012 at 2:20 PM, Scott Stults
wrote:
> I'm going to be building a Solr cluster and I want to have a rolling set of
> slices so that I can keep a fixed number of days in my collection. If I
> send an update to a particular slice leader, will it always hash the unique
> key and (prob
Hi solr user group,
Sorry if this isn't directly a Solr question. Seems like once in a blue moon
the GC crashes on a server in our Solr 3.6.1 slave farm. This seems to only
happen on a couple of the twelve slaves we have deployed and only very rarely
on those. It seems like this doesn't dire
Stick a javadoc patch in JIRA Jack?
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm
On Dec 18, 2012 2:23 PM, "Jack Krupansky" wrote:
> Yeah, and this is why I want it to be explicit.
>
> -- Jack Krupansky
>
> -Original Message- From: Dyer, James
> Sent: Tuesday, December 18
Robert,
Step 1 is to get the latest Java 7 or if you have to remain on 6 then use
the latest 6.
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm
On Dec 18, 2012 7:54 PM, "Petersen, Robert" wrote:
> Hi solr user group,
>
> ** **
>
> Sorry if this isn’t directly a Solr question.
I agree with James. Actually lucene tests will fail if a codec violates this.
Actually it goes much deeper than this.
>From the lucene apis, when you call IndexReader.document() with your
storedfieldVisitor, it must visit the fields in the original order
added.
so even if you do:
add("title", "
I would like to - gently - disagree that creating empty files is a
workaround. The issue as I see it is that a beginner would not even get to
the point of the 'create empty files', he/she would see the exception and
get all worried.
This is also problematic when writing an instruction, you tell so
Hi,
Could you try 4.0 or the latest 4.x along with the latest Java from Oracle?
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm
On Dec 18, 2012 10:19 PM, "Jam Luo" wrote:
> Hello,
>
> I deployed a solr-4.0-beta cluster, 4 shard, 2 peers in a shard. A peer
> catch exception:
> 十二月
On 12/18/2012 8:18 PM, Jam Luo wrote:
> I deployed a solr-4.0-beta cluster, 4 shard, 2 peers in a shard. A peer
> catch exception:
> 十二月 18, 2012 7:56:31 下午 org.apache.solr.common.SolrException log
> 严重: null:java.lang.RuntimeException: java.lang.OutOfMemoryError: unable to
> create new native thr
Finally got this to work --thank you Upayavira. Turns out the issue
was as a result of a syntax error in my stylesheet --I had
instread of :(
I didn't notice the xsltproc compilation errors before because it
processed the valid styles and printed out the errors at the beginning
of output.
compi
When I click on the ping link in the SOLR 3.3 Admin console I get error
below, Any suggestion how to fix it, besides completely rebuilding index:
Error:
description The server encountered an internal error (Ping query caused
exception: -1 org.apache.solr.common.SolrException: Ping query caused
Just in case someone comes across this, I've decided to use
UpdateRequestHandler [1] and it seems to be doing everything I want.
[1] http://wiki.apache.org/solr/UpdateRequestHandler
Lighton Phiri
http://lightonphiri.org
On 17 December 2012 17:06, Lighton Phiri wrote:
> Hello,
>
> First, apologi
We're planning to run Solr on our Windows cluster. The idea is to have one
"master" Solr which can update/insert documents and to keep the other
servers as readonly.
The Windows cluster is currently using DFSR to replicate files between the
servers and we wonder if we could use the DFSR to handle
46 matches
Mail list logo
