I wouldn't necessarily link FieldType.isPolyField() to the idea of a poly value source... they are two different things. For example, if NumericField had not already been written in Lucene, I would have perhaps just indexed both the lat and lon into the same lucene field. That part can be more of an implementation detail, and does not reflect the semantics of the field (the fact that it contains both a lat and lon).
-Yonik http://www.lucidimagination.com On Thu, Dec 10, 2009 at 1:16 PM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Dec 10, 2009, at 12:37 PM, Grant Ingersoll wrote: > >> OK, next up: >> >> How to handle the need to create multiple ValueSource instances for a given >> poly field? FieldType.getValueSource() only returns a single instance. >> >> I think there are a few options: >> >> 1. Change the signature above to return a list of ValueSources. This likely >> has back compat. issues. >> 2. Just change those functions that need to handle poly fields (the distance >> functions) to worry about them and realize that the other functions won't >> work with them >> 3. Punt and require the user to know the secret handshake that is the naming >> convention used. In some regard, this is no different than what any >> developer would experience now when using dynamic fields with function >> queries. > > 4. Create a derivative ValueSource called PolyValueSource that is a > ValueSource that can "expand" (kind of like a rewrite() method) to get the > "sub" ValueSources. Then, the functions that can work with a poly field can > check to see if the ValueSource is expandable and then do so. This way all > existing functions work as is, we just need to make a couple of changes in > the ValueSourceParser when dealing with the distance functions. This is a > combination of 1 and 2, essentially. > > 5. Yonik suggested modifying DocValues (DocValues.polyVal(double [] > valHolder) - Yonik called it getPoint(double [] val) but I think it should > be more generic since a poly field isn't point specific ) to be able to > return multiple values per Document. > GSI: I'm not sure this works w/o then needing to add in checks in the > functions themselves to deal w/ poly doc values, but I could be missing > something.
