I think if you have _root_ in schema.xml you should look elsewhere. My memory
is merely adding this one line to schema.xml took care of our problem.
From: Flowerday, Matthew J <matthew.flower...@gb.unisys.com>
Sent: Tuesday, January 12, 2021 3:23 AM
To: solr-user@lucene.apache.org
Subject: RE: Query over migrating a solr database from 7.7.1 to 8.7.0
Hi Jim
Thanks for getting back to me.
I checked the schema.xml that we are using and it has the line you mentioned:
<field name="_root_" type="string" indexed="true" stored="false"
docValues="false" />
And this is the only reference (apart from within a comment) for _root_ In the
schema.xml. Does your schema.xml have further references to _root_ that I could
need? I also checked out solrconfig.xml file for any references to _root_ and
there are none.
Many Thanks
Matthew
Matthew Flowerday | Consultant | ULEAF
Unisys | 01908 774830|
matthew.flower...@unisys.com<mailto:matthew.flower...@unisys.com>
Address Enigma | Wavendon Business Park | Wavendon | Milton Keynes | MK17 8LX
[unisys_logo]<http://www.unisys.com/>
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is for use only by the intended recipient. If you received this in
error, please contact the sender and delete the e-mail and its attachments from
all devices.
[Grey_LI]<http://www.linkedin.com/company/unisys> [Grey_TW]
<http://twitter.com/unisyscorp> [Grey_YT]
<http://www.youtube.com/theunisyschannel> [Grey_FB]
<http://www.facebook.com/unisyscorp> [Grey_Vimeo] <https://vimeo.com/unisys>
[Grey_UB] <http://blogs.unisys.com/>
From: Dyer, Jim
<james.d...@ingramcontent.com<mailto:james.d...@ingramcontent.com>>
Sent: 11 January 2021 22:58
To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
Subject: RE: Query over migrating a solr database from 7.7.1 to 8.7.0
EXTERNAL EMAIL - Be cautious of all links and attachments.
When we upgraded from 7.x to 8.x, I ran into an issue similar to yours: when
updating an existing document in the index, the document would be duplicated
instead of replaced as expected. The solution was to add a "_root_" field to
schema.xml like this:
<field name="_root_" type="string" indexed="true" stored="false"
docValues="false" />
It appeared that when a feature was added for nested documents, this field
somehow became mandatory in order for updates to work properly, at least in
some cases.
From: Flowerday, Matthew J
<matthew.flower...@gb.unisys.com<mailto:matthew.flower...@gb.unisys.com>>
Sent: Saturday, January 9, 2021 4:44 AM
To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
Subject: RE: Query over migrating a solr database from 7.7.1 to 8.7.0
Hi There
As a test I stopped Solr and ran the IndexUpgrader tool on the database to see
if this might fix the issue. It completed OK but unfortunately the issue still
occurs - a new version of the record on solr is created rather than updating
the original record.
It looks to me as if the record created under 7.7.1 is somehow not being
'marked as deleted' in the way that records created under 8.7.0 are. Is there a
way for these records to be marked as deleted when they are updated.
Many Thanks
Matthew
Matthew Flowerday | Consultant | ULEAF
Unisys | 01908 774830|
matthew.flower...@unisys.com<mailto:matthew.flower...@unisys.com>
Address Enigma | Wavendon Business Park | Wavendon | Milton Keynes | MK17 8LX
[unisys_logo]<http://www.unisys.com/>
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is for use only by the intended recipient. If you received this in
error, please contact the sender and delete the e-mail and its attachments from
all devices.
[Grey_LI]<http://www.linkedin.com/company/unisys> [Grey_TW]
<http://twitter.com/unisyscorp> [Grey_YT]
<http://www.youtube.com/theunisyschannel> [Grey_FB]
<http://www.facebook.com/unisyscorp> [Grey_Vimeo] <https://vimeo.com/unisys>
[Grey_UB] <http://blogs.unisys.com/>
From: Flowerday, Matthew J
<matthew.flower...@gb.unisys.com<mailto:matthew.flower...@gb.unisys.com>>
Sent: 07 January 2021 12:25
To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
Subject: Query over migrating a solr database from 7.7.1 to 8.7.0
Hi There
I have recently upgraded a solr database from 7.7.1 to 8.7.0 and not wiped the
database and re-indexed (as this would take too long to run on site).
On my local windows machine I have a single solr server 7.7.1 installation
I upgraded in the following manner
* Installed windows solr 8.7.0 on my machine in a different folder
* Copied the core related folder (holding conf, data, lib, core.properties)
from 7.7.1 to the new 8.7.0 folder
* Brought up the solr
* Checked that queries work through the Solr Admin Tool and our application
This all worked fine until I tried to update a record which had been created
under 7.7.1. Instead of marking the old record as deleted it effectively
created a new copy of the record with the change in and left the old image as
still visible. When I updated the record again it then correctly updated the
new 8.7.0 version without leaving the old image behind. If I created a new
record and then updated it the solr record would be updated correctly. The
issue only seemed to affect the old 7.7.1 created records.
An example of the duplication as follows (the first record is 7.7.1 created
version and the second record is the 8.7.0 version after carrying out an
update):
{
"responseHeader":{
"status":0,
"QTime":4,
"params":{
"q":"id:9901020319M01-N26",
"_":"1610016003669"}},
"response":{"numFound":2,"start":0,"numFoundExact":true,"docs":[
{
"id":"9901020319M01-N26",
"groupId":"9901020319M01",
"urn":"N26",
"specification":"nominal",
"owningGroupId":"9901020319M01",
"description":"N26, Yates, Mike, Alan, Richard, MALE",
"group_t":"9901020319M01",
"nominalUrn_t":"N26",
"dateTimeCreated_dtr":"2020-12-30T12:00:53Z",
"dateTimeCreated_dt":"2020-12-30T12:00:53Z",
"title_t":"Captain",
"surname_t":"Yates",
"qualifier_t":"Voyager",
"forename1_t":"Mike",
"forename2_t":"Alan",
"forename3_t":"Richard",
"sex_t":"MALE",
"orderedType_t":"Nominal",
"_version_":1687507566832123904},
{
"id":"9901020319M01-N26",
"groupId":"9901020319M01",
"urn":"N26",
"specification":"nominal",
"owningGroupId":"9901020319M01",
"description":"N26, Yates, Mike, Alan, Richard, MALE",
"group_t":"9901020319M01",
"nominalUrn_t":"N26",
"dateTimeCreated_dtr":"2020-12-30T12:00:53Z",
"dateTimeCreated_dt":"2020-12-30T12:00:53Z",
"title_t":"Captain",
"surname_t":"Yates",
"qualifier_t":"Voyager enterprise defiant yorktown xx yy",
"forename1_t":"Mike",
"forename2_t":"Alan",
"forename3_t":"Richard",
"sex_t":"MALE",
"orderedType_t":"Nominal",
"_version_":1688224966566215680}]
}}
I checked the solrconfig.xml file and it does have a uniqueKey set up
<field name="id" type="string" indexed="true" stored="true"
required="true" multiValued="false" />
<uniqueKey>id</uniqueKey>
I was wondering if this behaviour is expected and if there is a way to make
sure that records created under a previous version are updated correctly (so
that the old data is deleted when updated).
Also am I upgrading solr correctly as it could be that the way I have upgraded
it might be causing this issue (I tried hunting through the solr documentation
online but struggled to find window upgrade notes and the above steps I worked
out by trial and error).
Many thanks
Matthew
Matthew Flowerday | Consultant | ULEAF
Unisys | 01908 774830|
matthew.flower...@unisys.com<mailto:matthew.flower...@unisys.com>
Address Enigma | Wavendon Business Park | Wavendon | Milton Keynes | MK17 8LX
[unisys_logo]<http://www.unisys.com/>
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is for use only by the intended recipient. If you received this in
error, please contact the sender and delete the e-mail and its attachments from
all devices.
[Grey_LI]<http://www.linkedin.com/company/unisys> [Grey_TW]
<http://twitter.com/unisyscorp> [Grey_YT]
<http://www.youtube.com/theunisyschannel> [Grey_FB]
<http://www.facebook.com/unisyscorp> [Grey_Vimeo] <https://vimeo.com/unisys>
[Grey_UB] <http://blogs.unisys.com/>
