I’ve never used the managed schema, so I’m probably biased, but I’ve never seen much of a point to the Schema API.
I need to make changes sometimes to solrconfig.xml, in addition to schema.xml and other config files, and there’s no API for those, so my process has been like: 1. Put the entire config directory used by a collection in source control somewhere. solrconfig.xml, schema.xml, synonyms.txt, everything. 2. Make changes, test, commit 3. “Release” by uploading the whole config dir at a specific commit to ZK (overwriting any existing files) and issuing a collections API “reload”. This has the downside that I can upload a broken config and take down my collection, but with the whole config dir in source control, I can also easily roll back to any point by uploading an old commit. You still have to be aware of how the changes you’re making will effect your current index, but that’s unavoidable. On 12/3/15, 7:09 AM, "Kelly, Frank" <frank.ke...@here.com> wrote: >Just wondering if folks have any suggestions on using Schema.xml vs. >Managed Schema going forward. > >Our deployment will be >> 3 Zk, 3 Shards, 3 replicas >> Copies of each collection in 5 AWS regions (EBS-backed EC2 instances) >> Planning at least 1 Billion objects indexed (currently < 100 million) > >I'm sure our schema.xml will have changes and fixes and just wondering >which approach (schema.xml vs. managed) >will be easier to deploy / maintain? > >Cheers! > >-Frank > > >Frank Kelly >Principal Software Engineer >Predictive Analytics Team (SCBE/HAC/CDA) > > > > > > > >
