encryption for SSL-related passwords once we enable HTTPS in solr 8.6.2

[Phatkar, Swapnil (Contractor)]

Hi Team,

We are using Solr 8.6.2 for our application. We have enable https for it . We 
have to set following parameters for it .

SOLR_SSL_KEY_STORE
SOLR_SSL_KEY_STORE_PASSWORD
SOLR_SSL_TRUST_STORE
SOLR_SSL_TRUST_STORE_PASSWORD

We need to set value for SOLR_SSL_KEY_STORE_PASSWORD and 
SOLR_SSL_TRUST_STORE_PASSWORD as encrypted value .
Please suggest how we can do it and how it will be read ( decrypted ) by Solr ?

Thanks 
Swapnil Phatkar
9167320216

Re: Sorting is working in primitive multivalued fields without docValues

[Mónica Marrero]

Thank you! Yes, that is the quote, and here is the link to the
documentation where it is:
https://solr.apache.org/guide/7_7/common-query-parameters.html#sort-parameter

I have also tested with date types (also multivalued and with no docValues)
and in that case I get the following error:
"can not sort on a field w/o docValues unless it is indexed=true
uninvertible=true and the type supports Uninversion: ww_cc_deprecated_on"

The field:



I understand then that sorting is always allowed in fields that supports
uninversion, and that is not the case for all the primitive types.

Best,

Mónica

On Wed, 9 Jun 2021 at 20:00, Alessandro Benedetti 
wrote:

> From the wiki:
>
> The value of any primitive field (numerics, string, boolean, dates, etc.)
> > which has docValues="true" (or multiValued="false" and indexed="true", in
> > which case the indexed terms will used to build DocValue like structures
> on
> > the fly at runtime)
>
>
> I think the documentation is incorrect.
>
> Taking a look to the code:
>
> org.apache.solr.schema.PrimitiveFieldType#getDefaultMultiValueSelectorForSort
> 
> https://issues.apache.org/jira/browse/SOLR-11854
> https://github.com/apache/lucene-solr/commit/e2bba98/
>
> 
> I t seems the
> documentation was correct, at the time of the original Jira?
> Maybe a regression happened.
> Will spend some more time tomorrow
>
> --
> Alessandro Benedetti
> Apache Lucene/Solr Committer
> Director, R&D Software Engineer, Search Consultant
>
> www.sease.io
>
>
> On Wed, 9 Jun 2021 at 17:04, Alexandre Rafalovitch 
> wrote:
>
> > I am pretty sure your reality is correct and your document reading (or
> > document itself) is less than perfect. docValues are strongly
> > recommended if you are going to do a lot of sorting. But the ability
> > to sort existed before docValues were created.
> >
> > Can you send the specific (version-specific ideally) link and quote
> > that confuses you?
> >
> > Regards,
> >Alex.
> >
> > On Wed, 9 Jun 2021 at 11:02, Mónica Marrero  >
> > wrote:
> > >
> > > Hi,
> > >
> > > I am using Solr 7.7 in Cloud, and I had understood from the
> > > documentation that sorting is not possible in multivalued fields when
> > > docValues is not activated. To my surprise I am able to directly sort
> > (e.g.
> > > sort=CREATOR asc) using the two fields below (I also copy the
> definition
> > of
> > > the field types):
> > >
> > >  > > positionIncrementGap="0"/> class="solr.StrField"
> > > sortMissingLast="true" omitNorms="true"/>
> > >  > multiValued
> > > ="true"/>
> > >  > > multiValued="true"/>
> > >
> > > Am I missing something? The schema version is still 0.8 in case that
> > makes
> > > any difference.
> > >
> > > Thanks in advance for your help.
> > >
> > > --
> > > Disclaimer: This email and any files transmitted with it are
> confidential
> > > and intended solely for the use of the individual or entity to whom
> they
> > > are
> > > addressed. If you have received this email in error please notify the
> > > system manager. If you are not the named addressee you should not
> > > disseminate,
> > > distribute or copy this email. Please notify the sender
> > > immediately by email if you have received this email by mistake and
> > delete
> > > this email from your
> > > system.
> >
>

-- 
Disclaimer: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they 
are
addressed. If you have received this email in error please notify the 
system manager. If you are not the named addressee you should not 
disseminate,
distribute or copy this email. Please notify the sender 
immediately by email if you have received this email by mistake and delete 
this email from your
system.

Re: Sorting is working in primitive multivalued fields without docValues

[Alessandro Benedetti]

Hi Monica,
I think the trie fields are deprecated in favor of the point fields.

In regards to multi valued date sorting without docValues, the overall pull
request is the following:
https://github.com/apache/lucene-solr/commit/e2bba98/
I should investigate more but from a quick look , for dates we expect
exceptions in the tests, so *it seems* you are getting the supposed
behavior.
Didn't have time to fully investigate it and understand it, so I may be
wrong.

Cheers
--
Alessandro Benedetti
Apache Lucene/Solr Committer
Director, R&D Software Engineer, Search Consultant

www.sease.io


On Thu, 10 Jun 2021 at 09:22, Mónica Marrero 
wrote:

> Thank you! Yes, that is the quote, and here is the link to the
> documentation where it is:
>
> https://solr.apache.org/guide/7_7/common-query-parameters.html#sort-parameter
>
> I have also tested with date types (also multivalued and with no docValues)
> and in that case I get the following error:
> "can not sort on a field w/o docValues unless it is indexed=true
> uninvertible=true and the type supports Uninversion: ww_cc_deprecated_on"
>
> The field:
>  precisionStep="0" positionIncrementGap="0"/>
>  multiValued="true"/>
>
> I understand then that sorting is always allowed in fields that supports
> uninversion, and that is not the case for all the primitive types.
>
> Best,
>
> Mónica
>
> On Wed, 9 Jun 2021 at 20:00, Alessandro Benedetti 
> wrote:
>
> > From the wiki:
> >
> > The value of any primitive field (numerics, string, boolean, dates, etc.)
> > > which has docValues="true" (or multiValued="false" and indexed="true",
> in
> > > which case the indexed terms will used to build DocValue like
> structures
> > on
> > > the fly at runtime)
> >
> >
> > I think the documentation is incorrect.
> >
> > Taking a look to the code:
> >
> >
> org.apache.solr.schema.PrimitiveFieldType#getDefaultMultiValueSelectorForSort
> > 
> > https://issues.apache.org/jira/browse/SOLR-11854
> > https://github.com/apache/lucene-solr/commit/e2bba98/
> >
> > 
> > I t seems the
> > documentation was correct, at the time of the original Jira?
> > Maybe a regression happened.
> > Will spend some more time tomorrow
> >
> > --
> > Alessandro Benedetti
> > Apache Lucene/Solr Committer
> > Director, R&D Software Engineer, Search Consultant
> >
> > www.sease.io
> >
> >
> > On Wed, 9 Jun 2021 at 17:04, Alexandre Rafalovitch 
> > wrote:
> >
> > > I am pretty sure your reality is correct and your document reading (or
> > > document itself) is less than perfect. docValues are strongly
> > > recommended if you are going to do a lot of sorting. But the ability
> > > to sort existed before docValues were created.
> > >
> > > Can you send the specific (version-specific ideally) link and quote
> > > that confuses you?
> > >
> > > Regards,
> > >Alex.
> > >
> > > On Wed, 9 Jun 2021 at 11:02, Mónica Marrero <
> monica.marr...@europeana.eu
> > >
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am using Solr 7.7 in Cloud, and I had understood from the
> > > > documentation that sorting is not possible in multivalued fields when
> > > > docValues is not activated. To my surprise I am able to directly sort
> > > (e.g.
> > > > sort=CREATOR asc) using the two fields below (I also copy the
> > definition
> > > of
> > > > the field types):
> > > >
> > > >  > > > positionIncrementGap="0"/> > class="solr.StrField"
> > > > sortMissingLast="true" omitNorms="true"/>
> > > >  > > multiValued
> > > > ="true"/>
> > > >  > > > multiValued="true"/>
> > > >
> > > > Am I missing something? The schema version is still 0.8 in case that
> > > makes
> > > > any difference.
> > > >
> > > > Thanks in advance for your help.
> > > >
> > > > --
> > > > Disclaimer: This email and any files transmitted with it are
> > confidential
> > > > and intended solely for the use of the individual or entity to whom
> > they
> > > > are
> > > > addressed. If you have received this email in error please notify the
> > > > system manager. If you are not the named addressee you should not
> > > > disseminate,
> > > > distribute or copy this email. Please notify the sender
> > > > immediately by email if you have received this email by mistake and
> > > delete
> > > > this email from your
> > > > system.
> > >
> >
>
> --
> Disclaimer: This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to whom they
> are
> addressed. If you have received this email in error please notify the
> system manager. If you are not the named addressee you should not
> disseminate,
> distribute or copy this email. Please notify the sender
> immediately by email if you have received this email by mistake and delete
> this email from your
> system.
>

Re: Partial update error for missing _root_ after updating to Solr 8.8.2

[Andreas Hubold]

I have opened a JIRA ticket for this now
https://issues.apache.org/jira/browse/SOLR-15468

Would be great if someone could have a look and help.

Thank you,
Andreas



--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Forced index replication n Solr cloud

[Raveendra Yerraguntla]

All, 

Solr documentation mentioned about enable/disable replication between master 
and Solr nodes using collection APIs. Is there a way to force index Replication 
among the leader and replicas in one or some or all of the shards in a Solr 
cloud cluster ?

TA
Ravi

Re: encryption for SSL-related passwords once we enable HTTPS in solr 8.6.2

[Jan Høydahl]

I believe keystores are pluggable in Java, such as one delegating to Windows 
keychain, but I don't think they are in Solr. A simple solution would perhaps 
be a way to supply a password-file instead of a sysprop but it would require 
code changes to Solr.

Jan

> 10. jun. 2021 kl. 09:29 skrev Phatkar, Swapnil (Contractor) 
> :
> 
> Hi Team,
> 
> We are using Solr 8.6.2 for our application. We have enable https for it . We 
> have to set following parameters for it .
> 
> SOLR_SSL_KEY_STORE
> SOLR_SSL_KEY_STORE_PASSWORD
> SOLR_SSL_TRUST_STORE
> SOLR_SSL_TRUST_STORE_PASSWORD
> 
> We need to set value for SOLR_SSL_KEY_STORE_PASSWORD and 
> SOLR_SSL_TRUST_STORE_PASSWORD as encrypted value .
> Please suggest how we can do it and how it will be read ( decrypted ) by Solr 
> ?
> 
> Thanks 
> Swapnil Phatkar
> 9167320216

Re: encryption for SSL-related passwords once we enable HTTPS in solr 8.6.2

[Mark H. Wood]

On Thu, Jun 10, 2021 at 07:29:56AM +, Phatkar, Swapnil (Contractor) wrote:
> We are using Solr 8.6.2 for our application. We have enable https for it . We 
> have to set following parameters for it .
> 
> SOLR_SSL_KEY_STORE
> SOLR_SSL_KEY_STORE_PASSWORD
> SOLR_SSL_TRUST_STORE
> SOLR_SSL_TRUST_STORE_PASSWORD
> 
> We need to set value for SOLR_SSL_KEY_STORE_PASSWORD and 
> SOLR_SSL_TRUST_STORE_PASSWORD as encrypted value .
> Please suggest how we can do it and how it will be read ( decrypted ) by Solr 
> ?

A lot of people think that they want to do this.  Unfortunately it
always leads to an infinite regression:  the only way for Solr to
decrypt an encrypted password would be to give Solr the decryption
key.  But the decryption key is itself sensitive information that
should be encrypted, requiring a decryption key for the decryption
key

There are two ways out of this trap:

1:  do your best to keep unauthorized people away from the UNencrypted
store passwords and accept the small risk that your best will some
day not be good enough.  Usually it is not difficult to use
ordinary filesystem protections to make these data "secure enough".

2:  write the startup process to require that a trusted operator enter
the passwords at the console before Solr is started, so that they
are never stored on the system in any form.

You haven't described your threat model, so I can't advise which is
best for you.  I can say that I have never yet found it necessary to
choose option 2.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Partial update error for missing _root_ after updating to Solr 8.8.2

[David Smiley]

The follow-up here from JIRA is that, as of Solr 8.0, you must not add "_root_" 
to a schema for an existing collection.  Solr uses this field instead of the 
uniqueKey for certain identity checks.  Chaos will ensue if you add it later.  
I shall update the ref guide to add a warning.

~ David

On 2021/06/08 15:14:18, Andreas Hubold  wrote: 
> Hi,
> 
> with Solr 8.6.3 we developed a new feature that uses partial update to 
> add some nested documents to existing index documents.
> 
> Because we didn't have nested documents so far, we've added the _root_ 
> and _nest_path_ fields to the schema, but of course these were unset for 
> existing documents.
> 
>  docValues="true" />
>  name="_nest_path_" class="solr.NestPathField" />
> 
> With 8.6.3 it worked fine to use partial updates to set some nested 
> documents to existing docs. Nested documents itself were never changed 
> here, we're just setting the nested documents for existing top-level 
> documents.
> 
> I could also see that the _root_ field was correctly updated for both 
> root and child documents.
> 
> Now we've updated to Solr 8.8.2 and still want to use old indices where 
> the _root_ field isn't set for all documents. But now adding nested 
> documents doesn't work anymore:
> 
> Caused by: org.apache.solr.common.SolrException: Attempted an 
> atomic/partial update to a child doc without indicating the _root_ somehow.
>      at 
> org.apache.solr.handler.component.RealTimeGetComponent.getInputDocument(RealTimeGetComponent.java:746)
>      at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:689)
>      at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:373)
>      at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:336)
>      at 
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)
>      at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:336)
>      at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:222)
>      at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
> 
> This check was introduced with 
> https://issues.apache.org/jira/browse/SOLR-14923
> 
> I know, I could reindex everything, but I'd really really like to avoid 
> this.
> Is there some other kind of workaround that I could use with Solr 8.8.2?
> 
> Or would it be possible to change the check, so that it only throws an 
> exception if there's an existing(!) _root_ value in the indexed document 
> that doesn't match?
> 
> Thanks,
> Andreas
> 
> 

Get distinct count in json facet

[jay harkhani]

Hello,

We are using Solr v-6.1.0. We have 2 shards and 2 replica. In collection there 
are lakhs of documents. When make query it returns around 2 documents. We 
need distinct count based on docNumber field in json facet query.  We tried to 
use both unique and hll function but it not return accurate result. In unique 
function for more than 100 documents while in hll for more than 7000 documents 
it gives wrong result.

Some documents with field values as below:

docNumber   poi status
document 1  1   draft   abc
document 2  2   review
xyz
document 3
1   draft
xyz
document 4
3   review
abc
document 5
1   draft
abc

Following query used to get count from solr:

Using hll function:
json.facet={project_id:{type:terms,field:project_id,limit:100,facet:{distcount:"hll(docNumber)",status:{type:terms,field:status,limit:-1,facet:{distcount:"hll(docNumber)",poi:{type:terms,field:poi,limit:-1,facet:{distcount:"hll(docNumber)"}}}

Using unique function:
json.facet={project_id:{type:terms,field:project_id,limit:100,facet:{distcount:"unique(docNumber)",status:{type:terms,field:status,limit:-1,facet:{distcount:"unique(docNumber)",poi:{type:terms,field:poi,limit:-1,facet:{distcount:"unique(docNumber)"}}}

Please suggest approach to get distinct count in json.facet.

Regards,
Jay Harkhani.

Get distinct count in json facet

[jay harkhani]

Hello,

We are using Solr v-6.1.0. We have 2 shards and 2 replica. In collection there 
are lakhs of documents. When make query it returns around 2 documents. We 
need distinct count based on docNumber field in json facet query.  We tried to 
use both unique and hll function but it not return accurate result. In unique 
function for more than 100 documents while in hll for more than 7000 documents 
it gives wrong result.

Some documents with field values as below:
document 1: docNumber: 1, poi: draft, status: abc
document 2: docNumber: 2, poi: review, status: xyz
document 3: docNumber: 1, poi: draft, status: xyz
document 4: docNumber: 3, poi: review, status: abc
document 5: docNumber: 1, poi: draft, status: abc

Following query used to get count from solr:

Using hll function:
json.facet={project_id:{type:terms,field:project_id,limit:100,facet:{distcount:"hll(docNumber)",status:{type:terms,field:status,limit:-1,facet:{distcount:"hll(docNumber)",poi:{type:terms,field:poi,limit:-1,facet:{distcount:"hll(docNumber)"}}}

Using unique function:
json.facet={project_id:{type:terms,field:project_id,limit:100,facet:{distcount:"unique(docNumber)",status:{type:terms,field:status,limit:-1,facet:{distcount:"unique(docNumber)",poi:{type:terms,field:poi,limit:-1,facet:{distcount:"unique(docNumber)"}}}

Please suggest approach to get distinct count in json.facet.

Regards,
Jay Harkhani.

Facet domain change filter capabilities

[Hari Iyer]

Hi,
Is it possible to filter the changed domain (child) documents using fields from 
the original domain (parent) when faceting?

Consider an example of Order documents which have OrderItem documents as 
children (block join/nested).
Order -> fields: customerId, orderdate, type
OrderItem -> fields: productid, quantity, unitprice, type
I want to retrieve orders and items (a contrived scenario) where orderdate > 
DATE OR quantity > 10 and facet by customerId and sum(unitprice). This is 
rather like a SQL group by than a typical solr facet.

I can retrieve order documents based on that filter and facet by customerId.
I can then change the facet domain to orderitems (blockChildren) but the filter 
is not just based on orderitem documents. I need to get all orderitems if the 
(original domain) orderdate > DATE else get orderitems with quantity > 10.

“domain”: {
   “blockChildren”:”type:Order”,
   “filter”:”type:OrderItem AND (orderdate:[DATE TO *] OR quantity:[10 TO *])”
}

I am mixing parent and child document fields here without any qualification, 
and as expected the above doesn’t work (orderDate filter is always false). Is 
there support for this use-case at all?
Thanks,
Hari.

Re: Reads only on replicas?

[Stephen Lewis Bianamara]

Hi Community,

I checked the source and see that this doesn't look to be supported to read
only from followers. I guess this is possible by pulling the state.json
data from zookeeper, identifying the leaders, and then passing an explicit
whitelist not including the leaders. Can someone confirm that this is the
only way to accomplish this goal?

Thanks,
Stephen

On Tue, Jun 8, 2021 at 1:55 PM Stephen Lewis Bianamara <
stephen.bianam...@gmail.com> wrote:

> Hi Folks,
>
> Is it possible to configure a Solr cloud to serve reads only from the
> followers? I see this page
>  explains
> how to prefer by local, replica type, or sysprops. But is it possible to
> specify that something should be served by a non-leader whenever possible
> (or even require it to return at all)? E.g., something like
>
> shards.preference=leader:false
>
>
> Thanks,
> Stephen
>

Approaches to indexing indigenous languages?

[Peter Tyrrell]

I'm quite familiar with indexing English and French languages in Solr, but has 
anybody got any tips on indexing and querying (Canadian) indigenous First 
Nations languages? Depending on the language, terms may be written in a 
syllabic script (https://en.wikipedia.org/wiki/Canadian_Aboriginal_syllabics) 
or in Americanist phonetic notation 
(https://en.wikipedia.org/wiki/Americanist_phonetic_notation).


Peter

Peter Tyrrell, MLIS
Lead Developer at Andornot
1-866-266-2525 x706 / ptyrr...@andornot.com

Return name of the collection/core with the document

[ufuk yılmaz]

Is it possible to return which collection a matching document came from, when 
querying against an alias?

Suppose alias “myAlias” is pointing to collections c1, c2 and c3 and we are 
querying:

/solr/myAlias?q=id:123

I’m trying to get a response similar to:

[{ “id”: 123, “collection”: “c2”}]

Core name, shard name would be useful too, since I can extract collection name 
from them.

Is this achievable?

Thanks
~ufuk

Sent from Mail for Windows 10

Re: Reads only on replicas?

[Stephen Lewis Bianamara]

I've filed the Jira item to implement this here:

SOLR-15472  shards.preference
should support leader=false

On Thu, Jun 10, 2021 at 9:41 AM Stephen Lewis Bianamara <
stephen.bianam...@gmail.com> wrote:

> Hi Community,
>
> I checked the source and see that this doesn't look to be supported to
> read only from followers. I guess this is possible by pulling the
> state.json data from zookeeper, identifying the leaders, and then passing
> an explicit whitelist not including the leaders. Can someone confirm that
> this is the only way to accomplish this goal?
>
> Thanks,
> Stephen
>
> On Tue, Jun 8, 2021 at 1:55 PM Stephen Lewis Bianamara <
> stephen.bianam...@gmail.com> wrote:
>
>> Hi Folks,
>>
>> Is it possible to configure a Solr cloud to serve reads only from the
>> followers? I see this page
>>  explains
>> how to prefer by local, replica type, or sysprops. But is it possible to
>> specify that something should be served by a non-leader whenever possible
>> (or even require it to return at all)? E.g., something like
>>
>> shards.preference=leader:false
>>
>>
>> Thanks,
>> Stephen
>>
>

Re: Reads only on replicas?

[Walter Underwood]

What problem are you trying to solve with this?

Are you trying to send queries to less loaded machines? If so, this won’t do 
that.
Leaders only do a little bit more work than followers. All indexing processing 
is local
and that is most of the CPU usage.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 10, 2021, at 9:41 AM, Stephen Lewis Bianamara 
>  wrote:
> 
> Hi Community,
> 
> I checked the source and see that this doesn't look to be supported to read
> only from followers. I guess this is possible by pulling the state.json
> data from zookeeper, identifying the leaders, and then passing an explicit
> whitelist not including the leaders. Can someone confirm that this is the
> only way to accomplish this goal?
> 
> Thanks,
> Stephen
> 
> On Tue, Jun 8, 2021 at 1:55 PM Stephen Lewis Bianamara <
> stephen.bianam...@gmail.com> wrote:
> 
>> Hi Folks,
>> 
>> Is it possible to configure a Solr cloud to serve reads only from the
>> followers? I see this page
>>  explains
>> how to prefer by local, replica type, or sysprops. But is it possible to
>> specify that something should be served by a non-leader whenever possible
>> (or even require it to return at all)? E.g., something like
>> 
>> shards.preference=leader:false
>> 
>> 
>> Thanks,
>> Stephen
>> 

Re: Reads only on replicas?

[Dave]

I would think it would be as simple as deleting the update handler from your 
solrconfig on the search servers

> On Jun 10, 2021, at 6:28 PM, Walter Underwood  wrote:
> 
> What problem are you trying to solve with this?
> 
> Are you trying to send queries to less loaded machines? If so, this won’t do 
> that.
> Leaders only do a little bit more work than followers. All indexing 
> processing is local
> and that is most of the CPU usage.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
>> On Jun 10, 2021, at 9:41 AM, Stephen Lewis Bianamara 
>>  wrote:
>> 
>> Hi Community,
>> 
>> I checked the source and see that this doesn't look to be supported to read
>> only from followers. I guess this is possible by pulling the state.json
>> data from zookeeper, identifying the leaders, and then passing an explicit
>> whitelist not including the leaders. Can someone confirm that this is the
>> only way to accomplish this goal?
>> 
>> Thanks,
>> Stephen
>> 
>>> On Tue, Jun 8, 2021 at 1:55 PM Stephen Lewis Bianamara <
>>> stephen.bianam...@gmail.com> wrote:
>>> 
>>> Hi Folks,
>>> 
>>> Is it possible to configure a Solr cloud to serve reads only from the
>>> followers? I see this page
>>>  explains
>>> how to prefer by local, replica type, or sysprops. But is it possible to
>>> specify that something should be served by a non-leader whenever possible
>>> (or even require it to return at all)? E.g., something like
>>> 
>>> shards.preference=leader:false
>>> 
>>> 
>>> Thanks,
>>> Stephen
>>> 
> 

Re: Reads only on replicas?

[Shawn Heisey]

On 6/10/2021 5:08 PM, Dave wrote:

I would think it would be as simple as deleting the update handler from your 
solrconfig on the search servers


In SolrCloud, all cores for a collection use the same solrconfig.xml 
file, and it's in zookeeper.  Any solrconfig.xml file on the disk is 
ignored.


Your suggestion would be great for non-cloud deployments.

Thanks,
Shawn

Re: Solr transformer Peformance : [child] vs [subquery]

[Harshit Pandey]

Bump..

On Tue, Jun 8, 2021, 11:16 PM Harshit Pandey 
wrote:

>
> 
>
> Hi Solr users
>
> While reading through the solr docs
> ,
> it states '*[subquery] is an improvement over [child]'*.
>
> On deep diving through the docs 1,* [subquery] definitely *seems better
> wrt. the capabilities/offerings (sorting of nested documents, etc). It
> gives much more control as compared to the *[child]* transformer
>
> *But is it better (or equivalent)  in terms of performance as well ?*
>
> 1 of the requirements of my current project is to sort the child documents
> for every parent. *[child]* doesn't seem to have that support.
> *[subquery]* has it, but I am hesitant to migrate to it as it seems to be
> more expensive.
>
> As per my understanding, *[child]* only gets executed within the
> boundaries of the child docs for a given parent. Whereas *[subquery]* gets
> executed across the index. Hence the [*Subquery]* transformer seems to be
> more expensive than [*Child].* Please help in validating this hypothesis.
>
>
> "*Can I use the [subquery] transformer as efficiently as
> the [child] transformer itself ???*"
>
>
> Any details/insights wrt the performance comparisons will be appreciated.
>
>
> Thanks,
>
> Harshit
>
>
>
>