pvcnt commented on PR #1973:
URL: https://github.com/apache/solr/pull/1973#issuecomment-1767054461

   Sorry, I force pushed because I rebased against master (I had weird failures 
and hoped rebasing would help).
   
   Properties passed as `property.*` parameters in the CREATE collection 
command were never saved in state.json. They were just forwarded to the CREATE 
core command. Same for the ADDREPLICA command, `property.*` parameters were 
only forwarded to the CREATE core command. Hence possible inconsistencies, if 
one passes a custom property when creating a collection, but not later on when 
adding a replica.
   
   This PR really adds two things:
   1. Persist `property.*` parameters in state.json for collections and 
replicas (I did not tackle shards).
   2. Propagate those custom properties in ADDREPLICA calls to make sure that 
cores are created in a consistent way with the same properties. New cores 
inherit from properties from both the collection and replica, the latter 
overwriting properties from the former if they are found in both. This is of 
course only possible because they are stored in state.json.
   
   Please note that adding custom properties to collections and replicas is 
already supported via MODIFYCOLLECTION (**not** COLLECTIONPROP) and 
ADDREPLICAPROP commands, but this has no effect other than persisting them. 
Now, if those existing commands are used after creating a collection or 
replica, they would have the effect of affecting properties passed to new cores 
(but that would **never** change existing cores, their properties are immutable 
I guess).
   
   I hope this proposal brings one piece of answer to similar concerns raised 
about this situation raise in 
[SOLR-16305](https://issues.apache.org/jira/browse/SOLR-16305).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to