On Dec 10, 2009, at 11:30 PM, Mattmann, Chris A (388J) wrote: > Hi Yonik, > >>> While thinking about SOLR-1131, something important just came to mind. If we >>> allow poly fields to add fields to the schema (be it via dynamic fields, or >>> explicit field decls, either way), then we introduce a disconnect between >>> the existing XML schema, and the runtime schema instance. To my knowledge >>> there is no write-back/flush back for changes made to the schema at >>> run-time, and what's loaded on startup (correct me if I'm wrong). >> >> There are other pros/cons to dynamically inserting field definitions, >> but this isn't one of them I think (provided that created fields are >> deterministically created at the same time as the poly field.) >> There's no need to write-back. > > I disagree. Without defining the DynamicField's offline by editing the > schema.xml file before running SOLR, if fields are created on-the-fly by a > PolyField during SOLR runtime, the schema.xml file is out of sync with the > runtime IndexSchema instance.
By declaring the poly field, you are declaring the dynamic field. I don't see why this leads to drift. Sure, it is an abstraction and their are Lucene fields that will be created under the hood, but that is one of the primary features of Solr, it hides all that mess. Moreover, at startup, there is a check to make sure there are no name clashes. > >> >>> Also, I'm (ack!) now leaning towards >>> dynamic fields as a flexible method to do this (so long as they are >>> pre-declared in the schema.xml file explicitly) >> >> I think Grant & I are now on the same page about using dynamic fields. >> The remaining issue / option is if one must declare the dynamic >> fields in the schema, or if another field type (like a poly field, but >> it doesn't have to be) can insert the dynamic field definition if it >> doesn't exist. > > +1. My point is: one must declare the dynamic fields in the schema that the > poly fields will use, ahead of time or you risk the drift I'm talking about. > >> >>> -- that way you don't have >>> to create (n+10) * m fields for a 10-dimensional point that's stored as well >>> as indexed. >> >> AFAIK, there are no options currently on the table that would create >> (or require) field definitions for every poly-type field used. >> >> So perhaps we are actually all on the same page now (with the open >> question of if we should explicit define the dynamic field definition >> for the point type that will end up being added to the example >> schema). > > My +1 for being explicit rather than implicit -- let's require the > schema.xml editor person to define, ahead-of-time, the dynamicFiels that a > polyField will use. This will keep schema.xml and the runtime IndexSchema in > sync. > > Cheers, > Chris > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.mattm...@jpl.nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department University of > Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > -------------------------- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
