Currently gatherNodes only works on single value fields. You can seed a
gatherNodes with a facet() expression which works with multi-value fields,
but after that it only works with single value fields.
So you would have to index the data as a graph like this:
id, concept1, participant1
id, concep
Thank you very much for the quick response - will try - looks like need to
run solr as a solrCloud
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Json-APi-aggregation-specifiy-min-and-max-values-tp4324342p4324381.html
Sent from the Solr - User mailing list archive at N
I am trying to do a graph traversal query using gatherNode function. I am
seeding a streaming expression to get some documents and then I am trying
to map their ids(conceptid) to a multi valued field "participantIds" and
gather nodes.
Here is the query I am doing.
gatherNodes(collection1,
> sear
This query is supported by the parallel SQL interface (
https://cwiki.apache.org/confluence/display/solr/Parallel+SQL+Interface)
If you specify aggregationMode=facet it will use the json facet API under
the covers to get the result. There are more details about aggregation
modes in the docs. The H
Is it possible to get average of amount between two values(min and max
specified) in solr JSON Facet API results?
Ex: here is the query i need to apply in Solr
SELECT STATE, AVG(AMOUNT) from Table group by STATE having AVG(AMOUNT) >
3000 AND AVG(AMOUNT) < 5000
currently i am getting avg amounts
: From the first class, it seems similar to
: https://wiki.apache.org/solr/NegativeQueryProblems
See also: https://lucidworks.com/2011/12/28/why-not-and-or-and-not/
-Hoss
http://www.lucidworks.com/
: My temporary solution is to add the command line option "-s /bin/bash" to
: the solr init script by hand.
:
: Is there already a better way to avoid this manual modification?
:
: If not - might it be a good idea to add an option to the installation
: script in order to specify a shell?
If i u
Valid point on the soft commits. I'll try disabling them to see if there if
any change in performance as well. Worth a shot ;-)
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Friday, March 10, 2017 11:01 AM
To: solr-user
Subject: Re: SOLR 4.8.0 Master/
Glad to hear that. Do note that soft commits are irrelevant to
replication, all that matters are hard commits.
I'd go farther and disable soft commits, they don't serve much point
in master/slave, at least usually. The supposition in M/S setups is
that the master indexes but does not serve queries
My apologies. We're running 2 different sets of SOLR instances, the version
with the replication problems is 6.2.0 and NOT 4.8.0.
After reading your questions, I double checked the config and we're set to
autoCommit after a LONG time.
3600
true
Also using softCo
Hi Shawn,
Thanks for the info.
Regards,
Edwin
On 9 March 2017 at 23:09, Shawn Heisey wrote:
> On 3/8/2017 10:46 PM, Zheng Lin Edwin Yeo wrote:
> > Just to check, are the index that was indexed in Solr 6.4.1 affected
> > by the bug? Do we have to re-index those records when we move to Solr
> >
Hi Scott,
that could depend on a lot of things. Some questions:
* What is your commit policy? Explicit / auto / soft / hard ...
* "Other days things are off by a small amount between master and
slave"...what do you mean exactly? What is the behaviour you see in
terms of index versions bet
12 matches
Mail list logo