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.
