I know this is an old post, but I've seen the same behavior as well,
specifically in setting invariants. We had 2 cores with different
schema/solrconfig, but they both had a (differently configured) request handler
named /search. The invariants set in one core leached into requests for the
ot
Rich,
I've run into various problems with group.query and highlighting. You noted
one below (SOLR-5046), and there is also SOLR-6712, which might be related to
what you are experiencing. Still waiting for that patch to be reviewed...
-Original Message-
From: Rich Hume [mailto:rh...@id
Dirk,
There are 3 open JIRAs related to this behavior:
https://issues.apache.org/jira/browse/SOLR-3739
https://issues.apache.org/jira/browse/SOLR-3740
https://issues.apache.org/jira/browse/SOLR-3741
We worked around it by adding the explicit + signs if the query matched the
problematic pattern
s are there in the field you are grouping on?
How many results are you trying to group in a query?
Joel Bernstein
Search Engineer at Heliosearch
On Fri, Jan 30, 2015 at 4:10 PM, Cario, Elaine <
elaine.ca...@wolterskluwer.com> wrote:
> Hi Shamik,
>
> We use DocValues for groupin
Hi Shamik,
We use DocValues for grouping, and although I have nothing to compare it to (we
started with DocValues), we are also seeing similar poor results as you: easily
60% overhead compared to non-group queries. Looking around for some solution,
no quick fix is presenting itself unfortunate
I found this very ancient bit of code, not sure it even works anymore, but you
can give it a try. The problem isn't so much sending the request (if you've
got the original query with params, you can call Solr through a plain old HTTP
request), but it's parsing the response that's the tedious bi
Sudhaker,
Not sure if this has anything to do with your problem, but I had an issue with
grouping on non-string fields (in my case it was an integer) in SolrCloud
setup (4.7). But I was using internal fields. We worked around it by defining
the field as a string instead.
-Original Messa
If you have some control over the value of the facet, could you prefix each
facet value with the language, separated by some delimiter? (e.g.
EN/vegetarian, FR/vegeterian,...). Then use a facet.prefix to limit the facet
values returned for the language you want (e.g. facet.prefix=FR). Your
ap
Alessandro,
I just got this to work myself:
public static final String DEFINED_FIELDS_API = "/schema/fields";
public static final String DYNAMIC_FIELDS_API = "/schema/dynamicfields";
...
// just get a connection to Solr as usual (the factory is mine - it
will use CloudSol
Wondering if anyone else has this issue?
We have a grouping field which we defined as an integer; when we run a query
grouping on that field it works fine in a non-cloud configuration, but when we
try the same query in a SolrCloud configuration with multiple shards, we get
the following error:
Hi Giovanni,
I had the same issue just last week! I worked around it temporarily by
segmenting the file into < 1 MB files, and then using a comma-delimited list of
files in the filter specification in the schema.
There is a known issue around this:
https://issues.apache.org/jira/browse/SOLR-4
r per
config behavior is by design?
Thanks in advance.
From: Cario, Elaine
Sent: Friday, May 02, 2014 3:44 PM
To: 'solr-user@lucene.apache.org'
Subject: Can't use 2 highlighting components in the same solrconfig
Hoping someone can help me...
I'm trying to use both the Po
Hoping someone can help me...
I'm trying to use both the PostingsHighlighter and the FastVectorHighlighter in
the same solrconfig (selection driven by different request handlers), but once
I define 2 search components in the config, it always picks the Postings
Highlighter (even if I never refe
13 matches
Mail list logo
