[
https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932623#comment-17932623
]
Jason Gerlowski commented on SOLR-16305:
----------------------------------------
+1 to what others have already mentioned - that these "property" APIs are
difficult to keep straight and reason about. I don't have strong opinions on
the underlying implementation, but I'd love to help drive us towards a "single
read/write API", as David suggested.
Quick summary of the current state-of-play:
|| ||Write API||ReadAPI|| Visible for Plugins || Visible-for-Config ||
|Coll Creation Props | /admin/collections?action=CREATE...&property.foo=bar |
/admin/collections?action=COLSTATUS | DocCollection | Yep |
| Modify Collection Props |
/admin/collections?action=MODIFYCOLLECTION&property.foo=bar |
/admin/collections?action=COLSTATUS | DocCollection | Only to replicas created
after MODIFY |
| "COLLECTIONPROP" |
/admin/collections?action=COLLECTIONPROP&propertyName=foo&propertyValue=bar |
N/A | ZkStateReader.getCollectionProperties | Nope |
(The table above might've had a column to represent core.properties
persistence, but I omitted that as it seems like an implementation detail that
users are unlikely to care about. Am I missing something there?)
If the goal is for the most up-to-date property values to be visible to all
cores, then I think we've got two main approaches:
# Keep "core.properties" as the local "source of truth" for these properties,
but periodically update the file (say, at core-load time) to keep it up-to-date
with property changes in ZK.
# Add the ZK properties to the 'substitutableProperties' map used during config
parsing, irrespective of (or in addition to) the contents of core.properties.
Personally I lean towards the latter approach. Fetching properties out of ZK
right before a core-load feels less creaky and requires less machinery than
trying to keep 'N' core.properties files up to date. I'm ambivalent on where
specifically in ZK the properties live. State.json is probably the most
convenient place as there's already plumbing to populate `DocCollection`, etc.
from it. But maybe there's a "scaling" argument to keep props separate from
state.json (i.e. in collectionprops.json), so the two can be modified
independently of one another.
What does everyone else think? If folks are OK with the second approach in
general, I can come up with a more detailed writeup plan that covers APIs, etc.?
> MODIFYCOLLECTION with 'property.*' changes can't change values used in config
> file variables (even though they can be set during collection CREATE)
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16305
> URL: https://issues.apache.org/jira/browse/SOLR-16305
> Project: Solr
> Issue Type: Bug
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16305_test.patch
>
>
> Consider a configset with a {{solrconfig.xml}} that includes a snippet like
> this...
> {code:java}
> <str name="param.check">${custom.prop:customDefVal}</str>
> {code}
> ...this {{custom.prop}} can be set when doing a {{CREATE}} command for a
> collection that uses this configset, using the {{property.*}} prefix as noted
> in the reg-guide...
> {quote}{{property.{_}name{_}={_}value{_}}}
> |Optional|Default: none|
> Set core property _name_ to {_}value{_}. See the section [Core
> Discovery|https://solr.apache.org/guide/solr/latest/configuration-guide/core-discovery.html]
> for details on supported properties and values.
> {quote}
> ...BUT....
> These values can *not* be changed by using the {{MODIFYCOLLECTION}} command,
> in spite of the ref-guide indicating that it can be used to modify custom
> {{property.*}} attributes...
> {quote}The attributes that can be modified are:
> * {{replicationFactor}}
> * {{collection.configName}}
> * {{readOnly}}
> * other custom properties that use a {{property.}} prefix
> See the [CREATE
> action|https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create]
> section above for details on these attributes.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
