On Wed, Mar 6, 2013 at 7:50 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > 2) If you wish to use the /schema REST API for read and write operations, > then schema information will be persisted under the covers in a data store > whose format is an implementation detail just like the index file format.
This really needs to be driven by costs and benefits... There are clear benefits to having a simple human readable / editable file for the schema (whether it's on the local filesystem or on ZK). > The ability to say "my schema is a config file and i own it" should always > exist (remove it over my dead body) There are clear benefits to this being the persistence mechanism for the REST API. Even if the REST API persisted it's data in some binary format for example, then there would still need to be import/export mechanisms for the human readable/editable config file "config file" that should always exist. Why would we want any other intermediate format (i.e. "data" that is not human readable)? Seems like we should only introduce that extra complexity if the benefits are great enough. Actually, I just realized we already have this intermediate representation - it's the in-memory IndexSchema object. -Yonik http://lucidworks.com
