Hi Jan, On Mar 6, 2013, at 4:50 PM, Jan Høydahl <jan....@cominvent.com> wrote: > Will ZK get pushed the serialized monolithic schema.xml / schema.json from > the node which changed it, and then trigger an update to the rest of the > cluster?
Yes. > I was kind of hoping that once we have introduced ZK into the mix as our > centralized config server, we could start using it as such consistently. And > so instead of ZK storing a plain xml file, we split up the schema as native > ZK nodes […] Erik Hatcher made the same suggestion on SOLR-3251: <https://issues.apache.org/jira/browse/SOLR-3251?focusedCommentId=13571713&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13571713> My response on the issue: <https://issues.apache.org/jira/browse/SOLR-3251?focusedCommentId=13572774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13572774> In short, I'm not sure it's a good idea, and in any event, I don't want to implement this as part of the initial implementation - it could be added on later. > multiple collections may share the same config set and thus schema, so what > happens if someone does not know this and hits PUT > localhost:8983/solr/collection1/schema and it affects also the schema for > collection2? Hmm, that's a great question. Querying against a named config rather than a collection/core would not be an improvement, though, since the relationship between the two wouldn't be represented in the request. Maybe if there were requests that returned the collections using a particular named config, and vice versa, people could at least discover problematic dependencies before they send schema modificaiton requests? Or maybe such requests already exist? Steve
