Using classic schema is perfectly acceptable/reasonable, you can continue to do so freely (you'll have to change to ClassicSchemaFactory though).
Also, you can freely edit managed-schema just as you did schema.xml. The "trick" here is that you have to take some care _not_ to issue commands that modify the schema or the in-memory version will overwrite the one in ZK. Otherwise, though, you can freely use managed-schema just as you do classic schema. So you can do just what you do now, keep managed-schema in VCS and upconfig it. Also note that Solr 6.2 has "bin/solr zk upconfig/downconfig/cp/mv/ls" functionality. Managed lends itself to some kind of UI that maintains it. The process (IMO) for using that in prod would be something like: > Use the UI to build your schema > copy from ZK to your local machine > put the configs in VCS > Deploy using the VCS as your system-of-record. But that's just my approach. If you don't want to use the managed-schema features, switch back to classic IMO. Best, Erick On Wed, Jul 27, 2016 at 11:37 AM, Rachid Bouacheria <willi...@gmail.com> wrote: > Hi All, > > I am upgrading from solr 4 to 6. > In solr 4 I have a schema.xml that is under version control. > But solr 6 has the notion of a managed schema that could be modified via a > solr api call. > This seems great and flexible, but my assumption is that in this case > zookeeper becomes the authoritative copy and not SVN or Git. > > And this is where things become unclear to me. > Is the expectation to download the configuration from zk the same way we do > an svn checkout to have the configuration and run locally? > How do we know who changed what and when? > > I know that there still is the option to use schema.xml by using > the ClassicIndexSchemaFactory but I am curious to hear from y'all that use > managed schema how you are doing it and if there are any downside, gotchas, > or if all is just much better :-) > > Seems to me that running locally is harder as you cannot just checkout a > project that contains the up to date schema. > > Thank you, > Rachid.
