On Mon, Mar 11, 2013 at 2: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 cost is the user complexity of understanding what changes are > respected and when
There is going to be a cost to understanding any feature. This doesn't deal with the answer to the question "are we better off with or without this feature". >, and in hte implementation complexity of dealing with > changes coming from multiple code paths (both files changed on disk and > REST based request changes) Right - and these should be quantifiable going forward. In ZK mode, we need concurrency control anyway, so depending on the design, there may be really no cost at all. In local FS mode, it might be a very low cost (simply check the timestamp on the file for example). Code to re-read the schema and merge changes needs to be there anyway for cloud mode it seems. *If* we needed to, we could just assert that the schema file is the persistence mechanism, as opposed to the system of record, hence if you hand edit it and then use the API to change it, your hand edit may be lost. Or we may decide to do away with "local FS" mode altogether. I guess my main point is, we shouldn't decide a priori that using the API means you can no longer hand edit. My thoughts on this are probably heavily influenced on how I initially envisioned implementation working in cloud mode (which I thought about first since it's harder). A human readable file on ZK that represents the system of record for the schema seemed to be the best. I never even considered making it non-human readable (and thus non-editable by hand). -Yonik http://lucidworks.com
