RE: mergeindexes action does not seem to be merging cores.

[Piyush Kumar Nayak]

Yes that worked. 
Thanks Erick, for your help.


-Original Message-
From: Erick Erickson  
Sent: Tuesday, May 14, 2019 7:09 PM
To: solr-user@lucene.apache.org
Subject: Re: mergeindexes action does not seem to be merging cores.

Did you commit afterwards?

> On May 14, 2019, at 8:04 AM, Piyush Kumar Nayak  
> wrote:
> 
> Hi,
> 
> I don't seem to be able to get the merge core feature to work with Solr 7.2.1.
> I'm using the srcCore parameter method documented at 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fluce
> ne.apache.org%2Fsolr%2Fguide%2F6_6%2Fcoreadmin-api.html%23CoreAdminAPI
> -MERGEINDEXESdata=02%7C01%7Cpnayak%40adobe.com%7Cf5b4b1e2204749c7
> e8a208d6d871969d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63693437
> 9703364465sdata=sJ05%2Fm63PMNaaH3%2BHZXIw31xCFEPDuppIC2B4xe5rwQ%3
> Dreserved=0
> 
> I am making the following GET HTTP call using a browser:
> http://localhost:8991/solr/admin/cores?action=mergeindexes=mcol
> rcCore=col1=col2 In the call above the following cores are 
> referenced:
> merged core name: mcol
> core 1 name : fc1
> core 2 name : fc1
> All 3 cores preexist.
> 
> The response content I get is :
> {
>  "responseHeader":{
>"status":0,
>"QTime":57}}
> 
> I see the following in the logs:
> 747532 [qtp2028017635-17] INFO  org.apache.solr.servlet.HttpSolrCall  
> - [admin] webapp=null path=/admin/cores 
> params={core=mcx=mergeindexes=fcl1=fc2} 
> status=400 QTime=2
> 756577 [qtp2028017635-18] INFO  
> org.apache.solr.update.DirectUpdateHandler2  - start 
> mergeIndexes{NRTCachingDirectory(MMapDirectory@C:\collections\fc1\data
> \index 
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7c53c896
> ; maxCacheMB=48.0 
> maxMergeSizeMB=4.0),NRTCachingDirectory(MMapDirectory@C:\collections\f
> c2\data\index 
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@3e2255a5
> ; maxCacheMB=48.0 maxMergeSizeMB=4.0)}
> 756602 [qtp2028017635-18] INFO  
> org.apache.solr.update.DirectUpdateHandler2  - end_mergeIndexes
> 
> But the number of docs in the merged core do not increase post merge 
> operation. Search for keywords that exist in the core1 do not return results 
> with merged core.
> Am I missing something?
> 
> 
> Best regards,
> Piyush.

mergeindexes action does not seem to be merging cores.

[Piyush Kumar Nayak]

Hi,

I don't seem to be able to get the merge core feature to work with Solr 7.2.1.
I'm using the srcCore parameter method documented at 
https://lucene.apache.org/solr/guide/6_6/coreadmin-api.html#CoreAdminAPI-MERGEINDEXES

I am making the following GET HTTP call using a browser:
http://localhost:8991/solr/admin/cores?action=mergeindexes=mcol=col1=col2
In the call above the following cores are referenced:
merged core name: mcol
core 1 name : fc1
core 2 name : fc1
All 3 cores preexist.

The response content I get is :
{
  "responseHeader":{
"status":0,
"QTime":57}}

I see the following in the logs:
747532 [qtp2028017635-17] INFO  org.apache.solr.servlet.HttpSolrCall  - [admin] 
webapp=null path=/admin/cores 
params={core=mcx=mergeindexes=fcl1=fc2} status=400 
QTime=2
756577 [qtp2028017635-18] INFO  org.apache.solr.update.DirectUpdateHandler2  - 
start 
mergeIndexes{NRTCachingDirectory(MMapDirectory@C:\collections\fc1\data\index 
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7c53c896; 
maxCacheMB=48.0 
maxMergeSizeMB=4.0),NRTCachingDirectory(MMapDirectory@C:\collections\fc2\data\index
 lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@3e2255a5; 
maxCacheMB=48.0 maxMergeSizeMB=4.0)}
756602 [qtp2028017635-18] INFO  org.apache.solr.update.DirectUpdateHandler2  - 
end_mergeIndexes

But the number of docs in the merged core do not increase post merge operation. 
Search for keywords that exist in the core1 do not return results with merged 
core.
Am I missing something?


Best regards,
Piyush.

migrating cores with Solr upgrade

[Piyush Kumar Nayak]

Hi,

What is the best way to migrate cores from an old version of Solr (say 5.x) to 
a newer version (say 7.x). I did not find anything pertinent to the matter in 
the Solr reference guide.
Is there a tool that can do that seamlessly?

Regards,
Piyush.

RE: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

[Piyush Kumar Nayak]

Shawn,
I've raised a bug for the issue
https://issues.apache.org/jira/browse/SOLR-12340

have shared the schemas there, in case you wanna take a look.
Thanks for helping out.
 

-Original Message-
From: Shawn Heisey [mailto:apa...@elyograg.org] 
Sent: Thursday, May 10, 2018 3:41 AM
To: solr-user@lucene.apache.org
Subject: Re: change in the Standard Query Parser behavior when migrating from 
Solr 5 to 7.

On 5/9/2018 2:37 PM, Piyush Kumar Nayak wrote:
> Same here. "sow" restores the old behavior.

This might be a bug.  I'd like someone who has better understanding of the 
low-level internals to comment before assuming that it's a bug, though.  Sounds 
like sow=false (default as of 7.0) might be causing the 
autoGeneratePhraseQueries setting in the schema to be ignored.  Need to find 
out from an expert whether that is expected or wrong.

> The schema.xml in both Solr versions for me is the one that gets copied from 
> the default template folder to the collections's conf folder.
> On 7 though, looks like the schema changes file changes to "managed-schema".

The managed schema factory became default in 5.5.  The default filename for the 
managed schema is managed-schema.  Some of the configs included with Solr did 
already use the managed schema before it became default. Now all of the 
examples use the managed schema.

> On 7 Solr backs up the original schema.xml and creates a managed schema 
> config file.

That is a back-compat feature of the managed schema factory.  If a schema.xml 
file is found, it will be renamed and its contents will be copied to 
managed-schema, overwriting it if it exists already.

Thanks,
Shawn

RE: change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

[Piyush Kumar Nayak]

Same here. "sow" restores the old behavior.
The schema.xml in both Solr versions for me is the one that gets copied from 
the default template folder to the collections's conf folder.
On 7 though, looks like the schema changes file changes to "managed-schema".

The fieldtype that corresponds to field "contents" is "text", and the 
definition of "text" field in 5 and the schema backup on 7 is the same. 
On 7 Solr backs up the original schema.xml and creates a managed schema config 
file.

I tried the analysis tab. Looks like all the classes (WT, SF ...) in 7 list a 
property (termFrequency = 1) that is missing in 5.

Lemme see if I can share the schemas.


-Original Message-
From: David Hastings [mailto:hastings.recurs...@gmail.com] 
Sent: Thursday, May 10, 2018 1:38 AM
To: solr-user@lucene.apache.org
Subject: Re: change in the Standard Query Parser behavior when migrating from 
Solr 5 to 7.

sow=true made 7 mimic 5.



On Wed, May 9, 2018 at 3:57 PM, Shawn Heisey  wrote:

> On 5/9/2018 1:25 PM, David Hastings wrote:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpas
> > tebin.com%2F0QUseqrN=02%7C01%7Cpnayak%40adobe.com%7C2f18f520a2f
> > b463faabf08d5b5e89166%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
> > 36614932828978588=gs9zG65%2FMZayaIthXJZSbE6m%2FvjKd2uBPnRIta98
> > Haw%3D=0
> >
> > here is mine for an example with the exact same behavior
>
> Can you try the query in the Analysis tab in the admin UI on both 
> versions and see which step in the analysis chain is the point at 
> which the two diverge from each other?
>
> I would still like to see the full schema, but I have an idea for a 
> troubleshooting step.  Can you add "sow=true" to the URL on version 7 
> and see if that makes any difference?  The query that the OP is using 
> doesn't have spaces, but there might be some kind of odd interaction 
> between sow and other settings.  I believe the default value for sow 
> changed to false in version 7.
>
> You also might try setting autoGeneratePhraseQueries to false on the 
> fieldType, which might cause version 5 to behave the same as 7.  But 
> be warned that this could make things work very differently than users 
> might expect.
>
> Thanks,
> Shawn
>

change in the Standard Query Parser behavior when migrating from Solr 5 to 7.

[Piyush Kumar Nayak]

we have recently upgraded from Solr5 to Solr7. I'm running into a change of 
behavior that I cannot fathom.
For the term "test3" Solr7 splits the numeric and alphabetical components and 
does a simple term search while Solr 5 did a phrase search.
--
lucene/solr-spec: 7.2.1
http://localhost:8991/solr/solr4/select?q=test3=test=json=true=true

"debug":{
"rawquerystring":"test3",
"querystring":"test3",
"parsedquery":"contents:test contents:3",
"parsedquery_toString":"contents:test contents:3",

--
lucene/solr-spec 5.2.1
http://localhost:8989/solr/solr4/select?q=test3=test=json=true=true

"debug":{
"rawquerystring":"test3",
"querystring":"test3",
"parsedquery":"PhraseQuery(contents:\"test 3\")",
"parsedquery_toString":"contents:\"test 3\"",
--


I've not been able to find any mention of in the release notes or user guide at:
https://lucene.apache.org/solr/guide/7_3/major-changes-in-solr-7.html
https://lucene.apache.org/solr/guide/7_3/major-changes-from-solr-5-to-solr-6.html

Also, the fieldType name="text" in the schema.xml for the cores in both the 
versions of Solr are identical.
I'd appreciate any pointers that can help with explaining this change.

Thanks,
Piyush.