Why am I able to sort on a multiValued field?

[Andy C]

I am adding a new float field to my index that I want to perform range
searches and sorting on. It will only contain a single value.

I have an existing dynamic field definition in my schema.xml that I wanted
to use to avoid having to updating the schema:




I went ahead and implemented this in a test system (recently updated to
Solr 8.7), but then it occurred to me that I am not going to be able to
sort on the field because it is defined as multiValued.

But to my surprise sorting worked, and gave the expected results.Why? Can
this behavior be relied on in future releases?

Appreciate any insights.

Thanks
- AndyC -

Re: Updating configset

[Andy C]

Don't know if this is an option for you but the SolrJ Java Client library
has support for uploading a config set. If the config set already exists it
will overwrite it, and automatically RELOAD the dependent collection.

See
https://lucene.apache.org/solr/8_5_0/solr-solrj/org/apache/solr/common/cloud/ZkConfigManager.html

On Fri, Sep 11, 2020 at 1:45 PM Jörn Franke  wrote:

> I would go for the Solr rest api ... especially if you have a secured zk
> (eg with Kerberos). Then you need to manage access for humans only in Solr
> and not also in ZK.
>
> > Am 11.09.2020 um 19:41 schrieb Erick Erickson :
> >
> > Bin/solr zk upconfig...
> > Bin/solr zk cp... For individual files.
> >
> > Not as convenient as a nice API, but might let you get by...
> >
> >> On Fri, Sep 11, 2020, 13:26 Houston Putman 
> wrote:
> >>
> >> I completely agree, there should be a way to overwrite an existing
> >> configSet.
> >>
> >> Looks like https://issues.apache.org/jira/browse/SOLR-10391 already
> >> exists,
> >> so the work could be tracked there.
> >>
> >> On Fri, Sep 11, 2020 at 12:36 PM Tomás Fernández Löbbe <
> >> tomasflo...@gmail.com> wrote:
> >>
> >>> I was in the same situation recently. I think it would be nice to have
> >> the
> >>> configset UPLOAD command be able to override the existing configset
> >> instead
> >>> of just fail (with a parameter such as override=true or something). We
> >> need
> >>> to be careful with the trusted/unstrusted flag there, but that should
> be
> >>> possible.
> >>>
>  If we can’t modify the configset wholesale this way, is it possible to
> >>> create a new configset and swap the old collection to it?
> >>> You can create a new one and then call MODIFYCOLLECTION on the
> collection
> >>> that uses it:
> >>>
> >>>
> >>
> https://lucene.apache.org/solr/guide/8_6/collection-management.html#modifycollection-parameters
> >>> .
> >>> I've never used that though.
> >>>
> >>> On Fri, Sep 11, 2020 at 7:26 AM Carroll, Michael (ELS-PHI) <
> >>> m.carr...@elsevier.com> wrote:
> >>>
>  Hello,
> 
>  I am running SolrCloud in Kubernetes with Solr version 8.5.2.
> 
>  Is it possible to update a configset being used by a collection using
> a
>  SolrCloud API directly? I know that this is possible using the zkcli
> >> and
> >>> a
>  collection RELOAD. We essentially want to be able to checkout our
> >>> configset
>  from source control, and then replace everything in the active
> >> configset
> >>> in
>  SolrCloud (other than the schema.xml).
> 
>  We have a couple of custom plugins that use config files that reside
> in
>  the configset, and we don’t want to have to rebuild the collection or
>  access zookeeper directly if we don’t have to. If we can’t modify the
>  configset wholesale this way, is it possible to create a new configset
> >>> and
>  swap the old collection to it?
> 
>  Best,
>  Michael Carroll
> 
> >>>
> >>
>

Unable to get ICUFoldingFilterFactory class loaded in unsecured 8.4.1 SolrCloud

[Andy C]

I have a schema currently used with Solr 7.3.1 that uses the ICU contrib
extensions. Previously I used a  directive in the solrconfig.xml to
load the icu4j and lucene-analyzers-icu jars.

The 8.4 upgrade notes indicate that this approach is no longer supported
for SolrCloud unless you enable authentication. So I removed the 
directive from the solrconfig.xml.

I tried creating a 'lib' directory underneath solr-8.4.1\server\solr and
copying the jars there. However I get a ClassNotFoundException for
ICUFoldingFilterFactory class when I try creating a collection using the
uploaded configset. Adding an explicit "lib"
entry to the solr.xml (kept outside zookeeper), didn't help. (Note: both
these approaches work with a standalone 8.4.1 Solr instance).

I tried copying the 2 jars into the one of directories that are part of the
standard classpath, but that seems to cause problems with the class loader,
as I start getting a  NoClassDefFoundError :
org/apache/lucene/analysis/util/ResourceLoaderAware exception.

Any suggestions?

Thanks,
- Andy -

Re: Boolean Searches?

[Andy C]

Dave,

You don't mention what query parser you are using, but with the default
query parser you can field qualify all the terms entered in a text box by
surrounding them with parenthesis. So if you want to search against the
'title' field and they entered:

train OR dragon

You could generate the Solr query:

title:(train OR dragon)

Historically however Solr has not processed queries that contain a mixture
of boolean operators as expected. The problem is described here:
http://robotlibrarian.billdueber.com/2011/12/solr-and-boolean-operators/

There is an open JIRA for this (
https://issues.apache.org/jira/browse/SOLR-4023) so I assume the problem
still exists in the most recent releases.

On Thu, Mar 14, 2019 at 10:50 AM Dave Beckstrom 
wrote:

> Hi Everyone,
>
> I'm building a SOLR search application and the customer wants the search to
> work like google search.
>
>
> They want the user to be able to enter boolean searches like:
>
> train OR dragon.
>
> which would find any matches that has the word "train" or the word "dragon"
> in the title.
>
> I know that the SOLR search would like this:
>
> title:train OR title:dragon
>
> I am trying to avoid having to parse through what the user enters and build
> out complex search strings.
>
> Is there any way that I can build a search against the "title" field where
> if the user enters something like:
>
> train OR dragon AND 2
>
> it will hour the boolean AND/OR logic without my having to convert it into
> somethng nasty like:
>
> title:train OR title:dragon AND title:2
>
>
> Thank you!
>
> --
> *Fig Leaf Software, Inc.*
> https://www.figleaf.com/
> 
>
> Full-Service Solutions Integrator
>
>
>
>
>
>
>

Re: which Zookeper version for Solr 6.6.5

[Andy C]

Bernd,

I recently asked a similar question about Solr 7.3 and Zookeeper 3.4.11.

This is the response I found most helpful:

https://www.mail-archive.com/solr-user@lucene.apache.org/msg138910.html

- Andy -


On Fri, Dec 14, 2018 at 7:41 AM Bernd Fehling <
bernd.fehl...@uni-bielefeld.de> wrote:

> This question sounds simple but nevertheless its spinning in my head.
>
> While using Solr 6.6.5 in Cloud mode which has Apache ZooKeeper 3.4.10
> in the list of "Major Components" is it possible to use
> Apache ZooKeeper 3.4.13 as stand-alone ensemble together with SolrCloud
> 6.6.5
> or do I have to recompile SolrCloud 6.6.5 with Zookeeper 3.4.13 libraries?
>
> Regards
> Bernd
>

Re: Connection Problem with CloudSolrClient.Builder().build When passing a Zookeeper Addresses and RootParam

[Andy C]

>From the error, I think the issue is with your zookeeperList definition.

Try changing:


zookeeperList.add("http://100.12.119.10:2281";);
zookeeperList.add("http://100.12.119.10:2282";);
zookeeperList.add("http://100.12.119.10:2283";);

to


zookeeperList.add("100.12.119.10:2281");
zookeeperList.add("100.12.119.10:2282");
zookeeperList.add("100.12.119.10:2283");

If you are not using a chroot in Zookeeper then just use chrootOption =
Optional.empty(); (as you have done).

Intent of my code was to support both using a chroot and not using a
chroot. The value of _zkChroot is read from a config file in code not shown.

- Andy -

Re: Connection Problem with CloudSolrClient.Builder().build When passing a Zookeeper Addresses and RootParam

[Andy C]

I am using the following (Solr 7.3.1) successfully:

import java.util.Optional;

 Optional chrootOption = null;
 if (StringUtils.isNotBlank(_zkChroot))
 {
chrootOption = Optional.of(_zkChroot);
 }
 else
 {
chrootOption = Optional.empty();
 }
 CloudSolrClient client = new CloudSolrClient.Builder(_zkHostList,
chrootOption).build();

Adapted from code I found somewhere (unit test?). Intent is to support the
option of configuring a chroot or not (stored in "_zkChroot")

- Andy -

On Mon, Jun 18, 2018 at 12:53 PM, THADC 
wrote:

> Hello,
>
> I am using solr 7.3 and zookeeper 3.4.10. I have custom client code that is
> supposed to connect the a zookeeper cluster. For the sake of clarity, the
> main code focus:
>
>
> private synchronized void initSolrClient()
> {
> List zookeeperList = new ArrayList();
>
> zookeeperList.add("http://100.12.119.10:2281";);
> zookeeperList.add("http://100.12.119.10:2282";);
> zookeeperList.add("http://100.12.119.10:2283";);
>
> String collectionName = "myCollection"
>
> log.debug("in initSolrClient(), collectionName: " +
> collectionName);
>
> try {
> solrClient = new 
> CloudSolrClient.Builder(zookeeperList,
> null).build();
>
> } catch (Exception e) {
> log.info("Exception creating solr client object.
> ");
> e.printStackTrace();
> }
> solrClient.setDefaultCollection(collectionName);
> }
>
> Before executing, I test that all three zoo nodes are running
> (./bin/zkServer.sh status zoo.cfg, ./bin/zkServer.sh status zoo2.cfg,
> ./bin/zkServer.sh status zoo3.cfg). The status shows the quorum is
> up and running, with one nodes as the leader and the other two as
> followers.
>
> When I execute my java client to connect to the zookeeper cluster, I get :
>
> java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient$Builder.<
> init>(CloudSolrClient.java:1387)
>
>
> I am assuming it has a problem with my null value for zkChroot, but not
> certain. Th API says zkChroot is the path to the root ZooKeeper node
> containing Solr data. May be empty if Solr-data is located at the ZooKeeper
> root.
>
> I am confused on what exactly should go here, and when it can be null. I
> cannot find any coding examples.
>
> Any help greatly appreciated.
>
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>

Re: Performance if there is a large number of field

[Andy C]

Shawn,

Why are range searches more efficient than wildcard searches? I guess I
would have expected that they just provide different mechanism for defining
the range of unique terms that are of interest, and that the merge
processing would be identical.

Would a search such as:

field:c*

be more efficient if rewritten as:

field:[c TO d}

then?

On Fri, May 11, 2018 at 10:45 AM, Shawn Heisey  wrote:

> On 5/10/2018 2:22 PM, Deepak Goel wrote:
>
>> Are there any benchmarks for this approach? If not, I can give it a spin.
>> Also wondering if there are any alternative approach (i guess lucene
>> stores
>> data in a inverted field format)
>>
>
> Here is the only other query I know of that can find documents missing a
> field:
>
> q=*:* -field:*
>
> The potential problem with this query is that it uses a wildcard.  On
> non-point fields with very low cardinality, the performance might be
> similar.  But if the field is a Point type, or has a large number of unique
> values, then performance would be a lot worse than the range query I
> mentioned before.  The range query is the best general purpose option.
>
> The *:* query, despite appearances, does not use wildcards.  It is special
> query syntax.
>
> Thanks,
> Shawn
>
>

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

[Andy C]

Thanks Shawn. That makes sense.

On Wed, May 9, 2018 at 5:10 PM, Shawn Heisey  wrote:

> On 5/9/2018 2:38 PM, Andy C wrote:
> > Was not quite sure from reading the JIRA why the Zookeeper team felt the
> > issue was so critical that they felt the need to pull the release from
> > their mirrors.
>
> If somebody upgrades their servers from an earlier 3.4.x release to
> 3.4.11, then 3.4.11 might be unable to properly read the existing data
> because it'll be looking in the wrong place.  Worst-case scenario could
> result in all data in a ZK ensemble disappearing, and the admin might
> have no idea why it all disappeared.  (the data would probably still be
> recoverable from the disk)
>
> That's why it was pulled.
>
> > It does present something of a PR issue for us, if we tell our customers
> to
> > use a ZK version that has been pulled from the mirrors. Any plans to move
> > to ZK 3.4.12 in future releases?
>
> There should be no issues with running 3.4.12 servers with the 3.4.11
> client in Solr.  Other version combinations are likely to work as well,
> though there are typically a lot of bugfixes included in later ZK
> releases, so running the latest stable release is recommended.
>
> The ZOOKEEPER-2960 problem is ONLY on the server side.  As I mentioned
> before, the ZK version information in the release notes is not a
> recommendation, it serves to inform users what version of ZK is included
> in Solr.
>
> Thanks,
> Shawn
>
>

Re: Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

[Andy C]

Thank Erick.

Was not quite sure from reading the JIRA why the Zookeeper team felt the
issue was so critical that they felt the need to pull the release from
their mirrors.

I guess the biggest issue is if you started out with a single ZK instance
and then implemented a ZK cluster that it would invert the dataDir and
dataLogDir directories.

It does present something of a PR issue for us, if we tell our customers to
use a ZK version that has been pulled from the mirrors. Any plans to move
to ZK 3.4.12 in future releases?

Thanks,
- Andy -

On Wed, May 9, 2018 at 4:09 PM, Erick Erickson 
wrote:

> That bug isn't all that critical, at worst you may have to invert
> where your two directories point.
>
> 3.4.11 is available from https://archive.apache.org/dist/zookeeper/
>
> Best,
> Erick
>
> On Wed, May 9, 2018 at 12:51 PM, Andy C  wrote:
> > According to the 7.3 release notes I should be using Zookeeper 3.4.11
> with
> > Solr 7.3.
> >
> > However it appears that Zookeeper has pulled Zookeeper 3.4.11 from their
> > mirror sites (this appears to be due to a serious bug in ZK 3.4.11 -
> > ZOOKEEPER-2960) <https://issues.apache.org/jira/browse/ZOOKEEPER-2960> .
> > Only 3.4.10 and 3.4.12 are available.
> >
> > Not quite sure how to proceed. Can I use ZK 3.4.10 or 3.4.12 with Solr
> 7.3?
> > Or should I try to find an archived version of ZK 3.4.11 somewhere?
> >
> > Will Solr 7.3.1 or 7.4 be integrated with ZK 3.4.12? If so, what is the
> > expected time frame for these releases?
> >
> > Would appreciate any guidance.
> >
> > Thanks,
> > - Andy -
>

Upgrading to Solr 7.3 but Zookeeper 3.4.11 no longer available on Zookeeper mirror sites

[Andy C]

According to the 7.3 release notes I should be using Zookeeper 3.4.11 with
Solr 7.3.

However it appears that Zookeeper has pulled Zookeeper 3.4.11 from their
mirror sites (this appears to be due to a serious bug in ZK 3.4.11 -
ZOOKEEPER-2960)  .
Only 3.4.10 and 3.4.12 are available.

Not quite sure how to proceed. Can I use ZK 3.4.10 or 3.4.12 with Solr 7.3?
Or should I try to find an archived version of ZK 3.4.11 somewhere?

Will Solr 7.3.1 or 7.4 be integrated with ZK 3.4.12? If so, what is the
expected time frame for these releases?

Would appreciate any guidance.

Thanks,
- Andy -

Recovering from machine failure

[Andy C]

Running Solr 7.2 in SolrCloud mode with 5 Linux VMs. Each VM was a single
shard, no replication. Single Zookeeper instance running on the same VM as
one of the Solr instances.

IT was making changes, and 2 of the VMs won't reboot (including the VM
where Zookeeper is installed). There was a dedicated drive which Solr (and
Zookeeper for the one node) where installed on, and a dedicated drive where
the Solr indexes were created.

They believe the drives are still good. Their plan is to create 2 new VMs
and attach the drives from the old VMs to them. However the IP addresses of
the new VMs will be different.

In the solr.in.sh I had set the SOLR_HOST entry to the IP address of the
VM. Is this just an arbitrary name? Will Zookeeper still recognize the Solr
instance if the SOLR_HOST entry doesn't match the IP address.

Obviously I will need to adjust the ZK_HOST entries on all nodes to reflect
the new IP address of the VMs. But will that be sufficient?

Appreciate any guidance.

Thanks
- Andy -

Re: After upgrade to Solr 6.5, q.op=AND affects filter query differently than in older version

[Andy C]

Thanks for the response Shawn.

Adding "*:*" in front of my filter query does indeed resolve the issue. It
seems odd to me that the fully negated query does work if I don't set
q.op=AND. I guess this must be "adding complexity". Actually I just
discovered that that simply removing the extraneous outer parenthesis
[ fq=-ctindex:({*
TO "MyId"} OR {"MyId" TO *}) ] also resolved the issue.

Your state that the best performing query that gives the desired results is:

> fq=ctindex:myId OR (*:* -ctindex:[* TO *])

Is this because there some sort of optimization invoked when you use [* TO
*], or just because a single range will be more efficient than multiple
ranges ORed together?

I was considering generating an additional field "ctindex_populated" that
would contain true or false depending on whether a ctindex value is
present. And then changing the filter query to:

fq=ctindex_populated:false OR ctindex:myId

Would this be more efficient than your proposed filter query?

Thanks again,
- Andy -

On Mon, May 1, 2017 at 10:19 AM, Shawn Heisey  wrote:

> On 4/26/2017 1:04 PM, Andy C wrote:
> > I'm looking at upgrading the version of Solr used with our application
> from
> > 5.3 to 6.5.
> >
> > Having an issue with a change in the behavior of one of the filter
> queries
> > we generate.
> >
> > The field "ctindex" is only present in a subset of documents. It
> basically
> > contains a user id. For those documents where it is present, I only want
> > documents returned where the ctindex value matches the id of the user
> > performing the search. Documents with no ctindex value should be returned
> > as well.
> >
> > This is implemented through a filter query that excludes documents that
> > contain some other value in the ctindex field: fq=(-ctindex:({* TO
> "MyId"}
> > OR {"MyId" TO *}))
>
> I am surprised that this works in 5.3.  The crux of the problem is that
> fully negative query clauses do not actually work.
>
> Here's the best-performing query that gives you the results you want:
>
> fq=ctindex:myId OR (*:* -ctindex:[* TO *])
>
> The *:* is needed in the second clause to give the query a starting
> point of all documents, from which is subtracted all documents where
> ctindex has a value.  Without the "all docs" starting point, you are
> subtracting from nothing, which yields nothing.
>
> You may notice that this query works perfectly, and wonder why:
>
> fq=-ctindex:[* TO *]
>
> This works because on such a simple query, Solr is able to detect that
> it is fully negated, so it implicitly adds the *:* starting point for
> you.  As soon as you implement any kind of complexity (multiple clauses,
> parentheses, etc) that detection doesn't work.
>
> Thanks,
> Shawn
>
>

After upgrade to Solr 6.5, q.op=AND affects filter query differently than in older version

[Andy C]

I'm looking at upgrading the version of Solr used with our application from
5.3 to 6.5.

Having an issue with a change in the behavior of one of the filter queries
we generate.

The field "ctindex" is only present in a subset of documents. It basically
contains a user id. For those documents where it is present, I only want
documents returned where the ctindex value matches the id of the user
performing the search. Documents with no ctindex value should be returned
as well.

This is implemented through a filter query that excludes documents that
contain some other value in the ctindex field: fq=(-ctindex:({* TO "MyId"}
OR {"MyId" TO *}))

In 6.5 if q.op=AND I always get 0 results returned when the fq is used.
This wasn't the case in 5.3. If I remove the q.op parameter (or set it to
OR) I get the expected results.

I can reproduce this in the Solr Admin UI. If I enable debugQuery, the
parsed_filter_queries output is different with q.op=AND and with no q.op
parameter:

For q.op=AND I see: ["+(-(SolrRangeQuery(ctindex:{* TO MyId})
SolrRangeQuery(ctindex:{MyId TO *})))"]

With no q.op set I get: ["-(SolrRangeQuery(ctindex:{* TO MyId})
SolrRangeQuery(ctindex:{MyId TO *}))"]

In 5.3 I always get the same parsed_filter_queries output regardless of the
q.op setting: ["-(ctindex:{* TO MyId} ctindex:{MyId TO *})"]

Any idea what is going on, or how to make the behavior of this filter query
independent of the q.op setting?

More details:
- Using the standard query parser
- The fieldType of the ctindex field is "string"
- I upgraded to 6.5 by copying my 5.3 config files over, updating the
schema version to 1.6 in the schema.xml, updating the luceneMatchVersion to
6.5.0 in the solrconfig.xml, and building a brand new index.

Thanks,
- Andy -

Re: Overlapped Gap Facets

[Andy C]

You might want to look at using Interval Facets (
https://cwiki.apache.org/confluence/display/solr/Faceting#Faceting-IntervalFaceting)
in combination with relative dates specified using the Date Math feature (
https://cwiki.apache.org/confluence/display/solr/Working+with+Dates)

You would have to decide exactly what you mean by each of these intervals.
Does "Last 1 Day" mean  today (which could be specified by the interval
"[NOW/DAY, NOW/DAY+1DAYS)"), yesterday and today ("[NOW/DAY-1DAYS,
NOW/DAY+1DAYS)"), etc.

You could decide that you want it to mean the last 24 hours
("[NOW-1DAYS,NOW]"), but be aware that when you subsequently restrict your
query using one of these intervals using NOW without rounding has a
negative impact on the filter query cache (see
https://dzone.com/articles/solr-date-math-now-and-filter for a better
explanation than I could provide.

- Andy -

On Thu, Nov 17, 2016 at 10:46 AM, David Santamauro <
david.santama...@gmail.com> wrote:

>
> I had a similar question a while back but it was regarding date
> differences. Perhaps that might give you some ideas.
>
> http://lucene.472066.n3.nabble.com/date-difference-faceting-td4249364.html
>
> //
>
>
>
>
> On 11/17/2016 09:49 AM, Furkan KAMACI wrote:
>
>> Is it possible to do such a facet on a date field:
>>
>>   Last 1 Day
>>   Last 1 Week
>>   Last 1 Month
>>   Last 6 Month
>>   Last 1 Year
>>   Older than 1 Year
>>
>> which has overlapped facet gaps?
>>
>> Kind Regards,
>> Furkan KAMACI
>>
>>

Re: Zero value fails to match Positive, Negative, or Zero interval facet

[Andy C]

Upon further investigation this is a bug in Solr.

If I change the order of my interval definitions to be Negative, Zero,
Positive, instead of Negative, Positive, Zero it correctly assigns the
document with the zero value to the Zero interval.

I dug into the 5.3.1 code and the problem is in the
org.apache.solr.request.IntervalFacets class. When the getSortedIntervals()
method sorts the interval definitions for a field by their starting value
is doesn't take into account the startOpen property. When two intervals
have equal start values it needs to sort intervals where startOpen == false
before intervals where startOpen == true.

In the accumIntervalWithValue() method it checks which intervals each
document value should be considered a match for. It iterates through the
sorted intervals and stops checking subsequent intervals when
LOWER_THAN_START result is returned. If the Positive interval is sorted
before the Zero interval it never checks a zero value against the Zero
interval.

I modified the compareStart() implementation and it seems to work correctly
now (see below). I also compared the 5.3.1 version of the IntervalFacets
class against the 6.2.1 code, and it looks like the same issue will occur
in 6.2.1.

How should I proceed from here?

Thanks,
- Andy -

  private int compareStart(FacetInterval o1, FacetInterval o2) {
if (o1.start == null) {
  if (o2.start == null) {
return 0;
  }
  return -1;
}
if (o2.start == null) {
  return 1;
}
//return o1.start.compareTo(o2.start);
int startComparison = o1.start.compareTo(o2.start);
if (startComparison == 0) {
  if (o1.startOpen != o2.startOpen) {
if (!o1.startOpen) {
  return -1;
}
else {
  return 1;
}
  }
}
return startComparison;
  }

On Wed, Oct 19, 2016 at 2:47 PM, Andy C  wrote:

> I have a field called "SCALE_double" that is defined as multivalued with
> the fieldType "tdouble".
>
> "tdouble" is defined as:
>
>  omitNorms="true" positionIncrementGap="0"/>
>
> I have a document with the value "0" indexed for this field. I am able to
> successfully retrieve the document with the range query "SCALE_double:[0 TO
> 0]". However it doesn't match any of the interval facets I am trying to
> populate that match negative, zero, or positive values:
>
> "{!key=\"Negative\"}(*,0)",
> "{!key=\"Positive\"}(0,*]",
> "{!key=\"Zero\"}[0,0]"
>
> I assume this is some sort of precision issue with the TrieDoubleField
> implementation (if I change the Zero interval to
> "(-.01,+.01)" it now considers the document a match).
> However the range query works fine (I had assumed that the interval was
> just converted to a range query internally), and it fails to show up in the
> Negative or Positive intervals either.
>
> Any ideas what is going on, and if there is anything I can do to get this
> to work correctly? I am using Solr 5.3.1. I've pasted the output from the
> Solr Admin UI query below.
>
> Thanks,
> - Andy -
>
> {
>   "responseHeader": {
> "status": 0,
> "QTime": 0,
> "params": {
>   "facet": "true",
>   "fl": "SCALE_double",
>   "facet.mincount": "1",
>   "indent": "true",
>   "facet.interval": "SCALE_double",
>   "q": "SCALE_double:[0 TO 0]",
>   "facet.limit": "100",
>   "f.SCALE_double.facet.interval.set": [
> "{!key=\"Negative\"}(*,0)",
> "{!key=\"Positive\"}(0,*]",
> "{!key=\"Zero\"}[0,0]"
>   ],
>   "_": "1476900130184",
>   "wt": "json"
> }
>   },
>   "response": {
> "numFound": 1,
> "start": 0,
> "docs": [
>   {
> "SCALE_double": [
>   0
> ]
>   }
> ]
>   },
>   "facet_counts": {
> "facet_queries": {},
> "facet_fields": {},
> "facet_dates": {},
> "facet_ranges": {},
> "facet_intervals": {
>   "SCALE_double": {
> "Negative": 0,
> "Positive": 0,
> "Zero": 0
>   }
> },
> "facet_heatmaps": {}
>   }
> }
>

Zero value fails to match Positive, Negative, or Zero interval facet

[Andy C]

I have a field called "SCALE_double" that is defined as multivalued with
the fieldType "tdouble".

"tdouble" is defined as:



I have a document with the value "0" indexed for this field. I am able to
successfully retrieve the document with the range query "SCALE_double:[0 TO
0]". However it doesn't match any of the interval facets I am trying to
populate that match negative, zero, or positive values:

"{!key=\"Negative\"}(*,0)",
"{!key=\"Positive\"}(0,*]",
"{!key=\"Zero\"}[0,0]"

I assume this is some sort of precision issue with the TrieDoubleField
implementation (if I change the Zero interval to
"(-.01,+.01)" it now considers the document a match).
However the range query works fine (I had assumed that the interval was
just converted to a range query internally), and it fails to show up in the
Negative or Positive intervals either.

Any ideas what is going on, and if there is anything I can do to get this
to work correctly? I am using Solr 5.3.1. I've pasted the output from the
Solr Admin UI query below.

Thanks,
- Andy -

{
  "responseHeader": {
"status": 0,
"QTime": 0,
"params": {
  "facet": "true",
  "fl": "SCALE_double",
  "facet.mincount": "1",
  "indent": "true",
  "facet.interval": "SCALE_double",
  "q": "SCALE_double:[0 TO 0]",
  "facet.limit": "100",
  "f.SCALE_double.facet.interval.set": [
"{!key=\"Negative\"}(*,0)",
"{!key=\"Positive\"}(0,*]",
"{!key=\"Zero\"}[0,0]"
  ],
  "_": "1476900130184",
  "wt": "json"
}
  },
  "response": {
"numFound": 1,
"start": 0,
"docs": [
  {
"SCALE_double": [
  0
]
  }
]
  },
  "facet_counts": {
"facet_queries": {},
"facet_fields": {},
"facet_dates": {},
"facet_ranges": {},
"facet_intervals": {
  "SCALE_double": {
"Negative": 0,
"Positive": 0,
"Zero": 0
  }
},
"facet_heatmaps": {}
  }
}

Are there issues with the use of SolrCloud / embedded Zookeeper in non-HA deployments?

[Andy C]

We have integrated Solr 5.3.1 into our product. During installation
customers have the option of setting up a single Solr instance, or for high
availability deployments, multiple Solr instances in a master/slave
configuration.

We are looking at migrating to SolrCloud for HA deployments, but are
wondering if it makes sense to also use SolrCloud in non-HA deployments?

Our thought is that this would simplify things. We could use the same
approach for deploying our schema.xml and other configuration files on all
systems, we could always use the SolrJ CloudSolrClient class to communicate
with Solr, etc.

Would it make sense to use the embedded Zookeeper instance in this
situation? I have seen warning that the embedded Zookeeper should not be
used in production deployments, but the reason generally given is that if
Solr goes down Zookeeper will also go down, which doesn't seem relevant
here. Are there other reasons not to use the embedded Zookeeper?

More generally, are there downsides to using SolrCloud with a single
Zookeeper node and single Solr node?

Would appreciate any feedback.

Thanks,
Andy