I've been thinking about this in the background. I tossed out some of the idea's that were implemented here, and I also thought a properties file rather than xml might make the most sense for container config. After all, 99% of the things you set will be simple key->value props that are attributes of the cores tag. I thought, wouldn't that just be simple as a properties file? Easy hand wavy thought at the time.
I had forgotten that the shard handler configuration had crept into solr.xml. That made me think, what else will come creeping this way? Other solrconfig.xml stuff that doesn't belong per SolrCore. If my memory is right, shard handler was in solrconfig.xml at one point - so was the config for zookeeper in the very first integration attempt with Solr. Shouldn't the Container and SolrCore config mostly match? Wouldn't it be funny if was one yaml and the other xml? One a flat structure and the other nested? I think so. So I'm changing my mind on the properties files and favoring the use of the current solr.xml. It's a really easy switch for current users, it's consistent with what we have, and we can get 99% of the benefits of Erick's work even retaining solr.xml. I also think solr.xml and solrconfig.xml should be as similar as they can be. The real problem with solr.xml is still solved with Erick's work - the fact that cores are define there and Solr has to try and update the config file. The file is really not so bad once we remove that little ugly wart. I think there would be a few details to work out, but this path is very appealing to me. I don't think we should hurry this stuff - there is still some thread safety concerns I have, and I'm not sure it's gotten a lot of use since it's not part of the example or general tests. This is very important stuff IMO, and we want to get this change right, even if that means it doesn't make 4.3. 5x was almost invented for baking this type of change :) The faster we can come to a consensus, the faster we can get started baking things though. Anyone voting for the properties file? - Mark On Mar 14, 2013, at 3:46 PM, Robert Muir <[email protected]> wrote: > I'm late to the game here, so I apologize if a lot of this has already > been discussed... > > I was looking recently and a little confused about the new .properties > format, a few questions: > * is the current plan to deprecate the solr.xml support in 4.x and drop for > 5.0? > * is there a real advantage to the .properties format over the > existing .xml? When debugging it seemed I was in unknown territory a > little bit, and this sorta means going forward that everything in here > is assumed to be flat: but it isnt really today, and what if more > stuff needed to be added in the future that wasnt flat. For example > the shard handler stuff has nested elements, but i kinda had to guess > at how this mapped to .properties (since xml differentiates between > attributes and elements, but its not so clear with .properties). > > It seems to me there are two changes involved: > 1. ability to auto-discover cores from the filesystem so you don't > need to explicitly list them > 2. changing .xml format to .properties > > I guess just brainstorming, like what if we just kept the existing > .xml format? we could add a new "autoDiscover=true" attribute to the > cores element for people who don't want to list them explicitly. > Additionally we could make the file optional (in case you have no need > to configure anything in it). This might be less of an intrusive > change for 4.x too, as its a less radical change, just a new attribute > users can test if they want. Maybe we make it the default later in 5.x > but in general the format would still be the same, and we wouldnt need > the 2 different config implementations. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
