That's a good and valid point that applies most of the time. So is SOLR-646 ready to go now? Personally, I'm for getting 1.3 released now and polishing between 1.3 and 1.3.1.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, August 22, 2008 11:24:15 AM > Subject: Re: [jira] Commented: (SOLR-646) Configuration properties in > multicore.xml > > In genral that has been the recommendation from committers when we > make too many changes to the core .For instance SOLR-561 was > originally filed as as a single issue and now it is split into around > 6 issues according to the recommendation of committers. > > It helps us to move faster by focusing on a small problem at a time. > That also helps in paying attention to details of each small change > and finding out the easy way to solve a problem > > Another takeaway from this is that no committer would want to be > responsible for a regression in a release code . That can make them be > extremely cautious with what they commit. > > --Noble > > On Fri, Aug 22, 2008 at 6:28 PM, Henri Biestro (JIRA) wrote: > > > > [ > https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624813#action_12624813 > > ] > > > > Henri Biestro commented on SOLR-646: > > ------------------------------------ > > > > Given that: > > 1 - I've wasted too much time of too many people with a feature & code > > that's > too complex/wide > > 2 - The time & added delay it will take for me to create the sub-issues > > (for > the 2 bugs in CoreContainer, 1 bug & 1 rfe for persistence), modify this > issue > description & examples and create the code (although I'm not sure that's > needed > or a desirable) > > 3 - There is an alternate patch code ready that a committer has written > > that > he's comfortable with that solves the property expansion problem and he has > been > kind enough not to commit it already > > > > Let's use the efficient route: > > 1 - Push this solr-646 issue to a 'future release' date so it can be > > revisited > if ever needed or at least serve as an example of "things to not do when you > contribute" > > 2 - Create a new issue for 1.3 that is solved by the alternative patch, > > commit > it, close the issue & release 1.3 > > > > > > > > > > > > > >> Configuration properties in multicore.xml > >> ----------------------------------------- > >> > >> Key: SOLR-646 > >> URL: https://issues.apache.org/jira/browse/SOLR-646 > >> Project: Solr > >> Issue Type: New Feature > >> Affects Versions: 1.3 > >> Reporter: Henri Biestro > >> Assignee: Shalin Shekhar Mangar > >> Fix For: 1.3 > >> > >> Attachments: solr-646.patch, solr-646.patch, SOLR-646.patch, > solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch, solr-646.patch > >> > >> > >> This patch refers to 'generalized configuration properties' as specified > >> by > [HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834] > >> This means configuration & schema files can use expression based on > properties defined in *solr.xml*. > >> h3. Use cases: > >> Describe core data directories from solr.xml as properties. > >> Share the same schema and/or config file between multiple cores. > >> Share reusable fragments of schema & configuration between multiple cores. > >> h3. Usage: > >> h4. solr.xml > >> This *solr.xml* will be used to illustrates using properties for different > purpose. > >> {code:xml} > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> {code} > >> {{version}} : if you update your solr.xml or your cores for various > >> motives, > it can be useful to track of a version. In this example, this will be used to > define the {{dataDir}} for each core. > >> {{en-cores}},{{fr-cores}}: with aliases, if the list is long or > >> repetitive, > it might be convenient to use a property that can then be used to describe > the > Solr core name. > >> {{instanceDir}}: note that both cores will use the same instance > >> directory, > sharing their configuration and schema. The {{dataDir}} will be set for each > of > them from the *solrconfig.xml*. > >> h4. solrconfig.xml > >> This is where our *solr.xml* property are used to define the data > >> directory > as a composition of, in our example, the language code {{l10n}} and the core > version stored in {{version}}. > >> {code:xml} > >> > >> ${solr.solr.home}/data/${l10n}-${version} > >> .... > >> > >> {code} > >> h5. schema.xml > >> The {{include}} allows to import a file within the schema (or a > >> solrconfig); > this can help de-clutter long schemas or reuse parts. > >> {color:red}This is an experimental feature that may not be kept in the > future.{color} > >> The {{ctlField}} is just illustrating that a field & its type can be set > through properties as well; in our example, we will want the 'english' core > to > refer to an 'english-configured' field and the 'french' core to a > 'french-configured' one. The type for the field is defined as {{text-EN}} or > {{text-FR}} after expansion. > >> {code:xml} > >> > >> > >> ... > >> > >> > >> > >> ... > >> > stored="true" multiValued="true" /> > >> > >> {code} > >> This schema is importing this *text-l10n.xml* file which is a *fragment*; > >> the > fragment tag must be present & indicates the file is to be included. Our > example > only defines different stopwords for each language but you could of course > extend this to stemmers, synonyms, etc. > >> {code:xml} > >> > >> > positionIncrementGap="100"> > >> ... > >> > words="stopwords-fr.txt"/> > >> ... > >> > >> > positionIncrementGap="100"> > >> ... > >> > words="stopwords-en.txt"/> > >> ... > >> > >> > >> {code} > >> h4. Technical specifications > >> solr.xml can define properties at the multicore & each core level. > >> Properties defined in the multicore scope can override system properties. > >> Properties defined in a core scope can override multicore & system > properties. > >> Property definitions can use expressions to define their name & value; > >> these > expressions are evaluated in their outer scope context . > >> CoreContainer serialization keeps properties as defined; persistence is > idem-potent. (ie property expressions are written, not their evaluation). > >> The core descriptor properties are automatically defined in each core > context, namely: > >> solr.core.instanceDir > >> solr.core.name > >> solr.core.configName > >> solr.core.schemaName > >> h3. Coding notes: > >> - DOMUtil.java: > >> refactored substituteSystemProperties to use an Evaluator; > >> an Evaluator is a DOM visitor that expands property expressions "in place" > using a property map as an evaluation context > >> added an asString(node) method for logging purpose > >> - CoreDescriptor.java: > >> added an expression member to keep property expressions as defined in > solr.xml for persistence - allowing to write file as defined (not as expanded) > >> - CoreContainer.java: > >> add an expression member to keep property expression as defined in > >> solr.xml > for persistence - allowing to write file as defined (not as expanded); > >> solrx.xml peristence is idem-potent > >> added a local DOMUtil.Evaluator that tracks property expressions to > >> evaluate > & store them > >> *issues outlined through solr-646:* > >> fix in load: > >> CoreDescriptor p = new CoreDescriptor(this, names, ....); > >> was: CoreDescriptor p = new CoreDescriptor(this, name, ...); > >> fix in load; > >> register(aliases.get(a), core, false); > >> was of register(aliases.get(i), core, false); > >> - CoreAdminHandler.java > >> added an optional fileName to persist so it is possible to write the > >> solr.xml > to a different file (for comparison purpose) > >> - CoreAdminRequest.java > >> added PersistRequest to allow passing optional fileName > >> - Config.java: > >> subsituteProperties has been moved out of constructor & doc member made > protected to allow override > >> added an IncludesEvaluator that deals with include/fragment > >> - SolrConfig.java & IndexSchema.ava > >> added explicit calls to substituteProperties to perform property/include > expansion > >> - SolrResourceLoader.java > >> added properties member to store CoreContainer & per-SolrCore properties > >> added constructor properties parameter & getter for properties > >> - SolrProperties.java: > >> test inspired by MulticoreExampleTestBase.java > >> loads 2 cores sharing a schema & config; > >> config define dataDir using a property > >> schema uses a localization (l10n) property to define an attribute > >> persists the file to check it keeps the expression properties > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > > > > -- > --Noble Paul
