: >* What is the motivation/use case for editing the schema at runtime? : (I'm not suggesting there aren't good ones, just curious) : : to add new fields on the fly without having any search downtime
i haven't read anything in the jira issue this refrences, but in instances where reliability and uptime are of high concern, you'll typically have a master/multi-slave setup with the slaves sitting behind a load balancer -- in that configuration, you can deploy any change to your schema by: 1) stop rsyncd on the master 2) stop solr on master, change schema.xml on master, start solr on master 3) rebuild index from scratch on master (if needed) 4) disable snappuller on all slaves (can overlap step#3) 5) start rsyncd on master 6) take half your slaves out of your load balancers rotation 7) enable snappuller on the slaves out of rotation 8) do step#2 for the slaves out of rotation 9) swap which half of the slaves are in rotation 10) repeat steps 7 and 8 this process results in 0 downtime for any schema.xml change, regardless whether the changes require rebuilding your index. : things like default query parsing options and copy fields which : shouldn't require and index changes at all which why i went for a more : loose approach to start. if you change/add a copyField declaration, you'll need to reindex ... copyField is evaluated when a document is being indexed. -Hoss
