Re:Re: Converting a collection name to an alias

[xiefengchang]

I don't think you can achieve what you want---doing REAL rename.
why not just use collection alias? do you have any reason NOT to do that?

















At 2021-01-08 04:20:00, "Mike Drob"  wrote:
>I believe you may be able to use that command (or some combination of
>create alias commands) to create an alias from A to A, and then in
>the future when you want to change it you can have Alias A to collection B
>(assuming this is the point of the alias in the first place).
>
>On Thu, Jan 7, 2021 at 1:53 PM ufuk yılmaz 
>wrote:
>
>> Hi,
>> I’m aware of that API but it doesn’t do what I actually want.
>>
>> regards
>>
>> Sent from Mail for Windows 10
>>
>> From: matthew sporleder
>> Sent: 07 January 2021 22:46
>> To: solr-user@lucene.apache.org
>> Subject: Re: Converting a collection name to an alias
>>
>> https://lucene.apache.org/solr/guide/8_1/collections-api.html#rename
>>
>> On Thu, Jan 7, 2021 at 2:07 PM ufuk yılmaz 
>> wrote:
>> >
>> > Hi again,
>> >
>> > Lets say I have a collection named A.
>> > I’m trying to rename it to A_1, then create an alias named A, which
>> points to the A_1 collection.
>> > Is this possible without deleting and reindexing the collection from
>> scratch?
>> >
>> > Regards,
>> > uyilmaz
>> >
>>
>>

Re:[Solr8.7] Indexing only some language ?

[xiefengchang]

Take a look at the document here: 
https://lucene.apache.org/solr/guide/8_7/dynamic-fields.html#dynamic-fields


here's the point: "a field that does not match any explicitly defined fields 
can be matched with a dynamic field."


so I guess the priority is quite clear~

















At 2021-01-10 03:38:01, "Bruno Mannina"  wrote:
>Hello,
>
>
>
>I would like to define in my schema.xml some text_xx fields.
>
>I have patent titles in several languages.
>
>Only 6 of them (EN, IT, FR, PT, ES, DE) interest me.
>
>
>
>I know how to define these 6 fields, I use text_en, text_it etc.
>
>
>
>i.e. for English language:
>
>stored="true" termVectors="true" termPositions="true" termOffsets="true"/>
>
>
>
>But I have more than 6 languages like: AR, CN, JP, KR etc.
>
>I can't analyze all source files to detect all languages and define them in
>my schema.
>
>
>
>I would like to use a dynamic field to index other languages.
>
>indexed="true" stored="true" omitTermFreqAndPositions="true"
>omitNorms="true"/>
>
>
>
>Is it ok to do that?
>
>Is TIEN field will be indexed twice internally or as tien is already defined
>ti* will not process tien?
>
>
>
>Thanks for your kind reply,
>
>
>
>Sincerely
>
>Bruno
>
>
>
>
>
>
>
>
>
>--
>L'absence de virus dans ce courrier électronique a été vérifiée par le 
>logiciel antivirus Avast.
>https://www.avast.com/antivirus

Re: StandardTokenizerFactory doesn't split on underscore

[Rahul Goswami]

Ah ok! Thanks Adam and Xiefeng

On Sat, Jan 9, 2021 at 6:02 PM Adam Walz  wrote:

> It is expected that the StandardTokenizer will not break on underscores.
> The StandardTokenizer follows the Unicode UAX 29
>  standard which
> specifies an underscore as an "extender" and this rule
>  says to not break from
> extenders.
> This is why xiefengchang was suggesting to use a
> PatternReplaceFilterFactory after the StandardTokenizer in order to further
> split on underscores if that is your use case.
>
> On Sat, Jan 9, 2021 at 2:58 PM Rahul Goswami 
> wrote:
>
> > Nope. The underscore is preserved right after tokenization even before it
> > reaches any filters. You can choose the type "text_general" and try an
> > index time analysis through the "Analysis" page on Solr Admin UI.
> >
> > Thanks,
> > Rahul
> >
> > On Sat, Jan 9, 2021 at 8:22 AM xiefengchang 
> > wrote:
> >
> > > did you configured PatternReplaceFilterFactory?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > At 2021-01-08 12:16:06, "Rahul Goswami"  wrote:
> > > >Hello,
> > > >So recently I was debugging a problem on Solr 7.7.2 where the query
> > wasn't
> > > >returning the desired results. Turned out that the indexed terms had
> > > >underscore separated terms, but the query didn't. I was under the
> > > >impression that terms separated by underscore are also tokenized by
> > > >StandardTokenizerFactory, but turns out that's not the case. Eg:
> > > >'hello-world' would be tokenized into 'hello' and 'world', but
> > > >'hello_world' is treated as a single token.
> > > >Is this a bug or a designed behavior?
> > > >
> > > >If this is by design, it would be helpful if this behavior is included
> > in
> > > >the documentation since it is similar to the behavior with periods.
> > > >
> > > >
> > >
> >
> https://lucene.apache.org/solr/guide/6_6/tokenizers.html#Tokenizers-StandardTokenizer
> > > >"Periods (dots) that are not followed by whitespace are kept as part
> of
> > > the
> > > >token, including Internet domain names. "
> > > >
> > > >Thanks,
> > > >Rahul
> > >
> >
>
>
> --
> Adam Walz
>

Re: StandardTokenizerFactory doesn't split on underscore

[Adam Walz]

It is expected that the StandardTokenizer will not break on underscores.
The StandardTokenizer follows the Unicode UAX 29
 standard which
specifies an underscore as an "extender" and this rule
 says to not break from extenders.
This is why xiefengchang was suggesting to use a
PatternReplaceFilterFactory after the StandardTokenizer in order to further
split on underscores if that is your use case.

On Sat, Jan 9, 2021 at 2:58 PM Rahul Goswami  wrote:

> Nope. The underscore is preserved right after tokenization even before it
> reaches any filters. You can choose the type "text_general" and try an
> index time analysis through the "Analysis" page on Solr Admin UI.
>
> Thanks,
> Rahul
>
> On Sat, Jan 9, 2021 at 8:22 AM xiefengchang 
> wrote:
>
> > did you configured PatternReplaceFilterFactory?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > At 2021-01-08 12:16:06, "Rahul Goswami"  wrote:
> > >Hello,
> > >So recently I was debugging a problem on Solr 7.7.2 where the query
> wasn't
> > >returning the desired results. Turned out that the indexed terms had
> > >underscore separated terms, but the query didn't. I was under the
> > >impression that terms separated by underscore are also tokenized by
> > >StandardTokenizerFactory, but turns out that's not the case. Eg:
> > >'hello-world' would be tokenized into 'hello' and 'world', but
> > >'hello_world' is treated as a single token.
> > >Is this a bug or a designed behavior?
> > >
> > >If this is by design, it would be helpful if this behavior is included
> in
> > >the documentation since it is similar to the behavior with periods.
> > >
> > >
> >
> https://lucene.apache.org/solr/guide/6_6/tokenizers.html#Tokenizers-StandardTokenizer
> > >"Periods (dots) that are not followed by whitespace are kept as part of
> > the
> > >token, including Internet domain names. "
> > >
> > >Thanks,
> > >Rahul
> >
>


-- 
Adam Walz

Re: StandardTokenizerFactory doesn't split on underscore

[Rahul Goswami]

Nope. The underscore is preserved right after tokenization even before it
reaches any filters. You can choose the type "text_general" and try an
index time analysis through the "Analysis" page on Solr Admin UI.

Thanks,
Rahul

On Sat, Jan 9, 2021 at 8:22 AM xiefengchang  wrote:

> did you configured PatternReplaceFilterFactory?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> At 2021-01-08 12:16:06, "Rahul Goswami"  wrote:
> >Hello,
> >So recently I was debugging a problem on Solr 7.7.2 where the query wasn't
> >returning the desired results. Turned out that the indexed terms had
> >underscore separated terms, but the query didn't. I was under the
> >impression that terms separated by underscore are also tokenized by
> >StandardTokenizerFactory, but turns out that's not the case. Eg:
> >'hello-world' would be tokenized into 'hello' and 'world', but
> >'hello_world' is treated as a single token.
> >Is this a bug or a designed behavior?
> >
> >If this is by design, it would be helpful if this behavior is included in
> >the documentation since it is similar to the behavior with periods.
> >
> >
> https://lucene.apache.org/solr/guide/6_6/tokenizers.html#Tokenizers-StandardTokenizer
> >"Periods (dots) that are not followed by whitespace are kept as part of
> the
> >token, including Internet domain names. "
> >
> >Thanks,
> >Rahul
>

Re: Solr query with space (only) gives error

[vstuart]

Cross-posted / addressed (both me), here.

https://stackoverflow.com/questions/65620642/solr-query-with-space-only-q-20-stalls/65638561#65638561



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

Re: Solr query with space (only) gives error

[vstuart]

Cross-posted / addressed (both me), here.

https://stackoverflow.com/questions/65620642/solr-query-with-space-only-q-20-stalls/65638561#65638561



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

[Solr8.7] Indexing only some language ?

[Bruno Mannina]

Hello,



I would like to define in my schema.xml some text_xx fields.

I have patent titles in several languages.

Only 6 of them (EN, IT, FR, PT, ES, DE) interest me.



I know how to define these 6 fields, I use text_en, text_it etc.



i.e. for English language:





But I have more than 6 languages like: AR, CN, JP, KR etc.

I can't analyze all source files to detect all languages and define them in
my schema.



I would like to use a dynamic field to index other languages.





Is it ok to do that?

Is TIEN field will be indexed twice internally or as tien is already defined
ti* will not process tien?



Thanks for your kind reply,



Sincerely

Bruno









--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re:StandardTokenizerFactory doesn't split on underscore

[xiefengchang]

did you configured PatternReplaceFilterFactory?

















At 2021-01-08 12:16:06, "Rahul Goswami"  wrote:
>Hello,
>So recently I was debugging a problem on Solr 7.7.2 where the query wasn't
>returning the desired results. Turned out that the indexed terms had
>underscore separated terms, but the query didn't. I was under the
>impression that terms separated by underscore are also tokenized by
>StandardTokenizerFactory, but turns out that's not the case. Eg:
>'hello-world' would be tokenized into 'hello' and 'world', but
>'hello_world' is treated as a single token.
>Is this a bug or a designed behavior?
>
>If this is by design, it would be helpful if this behavior is included in
>the documentation since it is similar to the behavior with periods.
>
>https://lucene.apache.org/solr/guide/6_6/tokenizers.html#Tokenizers-StandardTokenizer
>"Periods (dots) that are not followed by whitespace are kept as part of the
>token, including Internet domain names. "
>
>Thanks,
>Rahul

Re:Remote error message: empty String & null:java.lang.NumberFormatException: empty String

[xiefengchang]

why don't you check what is it trying to do number conversion? at least the 
numberformatException is quite clear

















At 2021-01-08 20:07:24, "Doss"  wrote:
>We have 12 node SOLR cloud with 3 zookeeper ensemble
>RAM: 80 CPU:40 Heap:16GB Records: 4 Million
>
>We do real time update and deletes (by ID), and we do us Inplace updates
>for 4 fields
>
>We have one index with 4 shards: 1 shard in 3 nodes
>
>Often we are getting the following errors
>
>1. *2021-01-08 17:11:14.305 ERROR (qtp1720891078-7429) [c:profilesindex
>s:shard4 r:core_node42 x:profilesindex_shard4_replica_n41]
>o.a.s.s.HttpSolrCall
>null:org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException:
>Async exception during distributed update: Error from server at
>http://171.0.0.145:8983/solr/profilesindex_shard3_replica_n49/
>: null*
>
>request: http://171.0.0.145:8983/solr/profilesindex_shard3_replica_n49/
>Remote error message: empty String
>at
>org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1193)
>at
>org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1125)
>at
>org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
>at
>org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
>at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
>at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
>at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
>at
>org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
>at
>org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
>at
>org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
>at
>org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>at
>org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
>at
>org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
>at
>org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
>at
>org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
>at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
>at
>org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
>at
>org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>at
>org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
>at
>org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
>at
>org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
>at
>org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>at
>org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
>at
>org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>at org.eclipse.jetty.server.Server.handle(Server.java:500)
>at
>org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
>at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
>at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
>at
>org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
>at
>org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
>at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
>at
>org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
>at
>org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
>at
>org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
>at
>org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
>at
>org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
>at
>org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
>at
>org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
>at java.base/java.lang.Thread.run(Thread.java:832)

Re: Query over migrating a solr database from 7.7.1 to 8.7.0

[matthew sporleder]

Did you commit?

> On Jan 9, 2021, at 5:44 AM, Flowerday, Matthew J 
>  wrote:
> 
> 
> 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
> Address Enigma | Wavendon Business Park | Wavendon | Milton Keynes | MK17 8LX
>  
> 
>  
> 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.
> 
>  
> 
>  
> 
> 
> 
> 
>  
> From: Flowerday, Matthew J  
> Sent: 07 January 2021 12:25
> To: 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
>  
>required="true" multiValued="false" />
>  
> id
>  
> 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 | 

RE: Query over migrating a solr database from 7.7.1 to 8.7.0

[Flowerday, Matthew J]

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 

Address Enigma | Wavendon Business Park | Wavendon | Milton Keynes | MK17
8LX

 

  

 

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.

 

  
 

 

From: Flowerday, Matthew J  
Sent: 07 January 2021 12:25
To: 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

 

  

  

id

 

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