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.
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
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
On Dec 10, 2009, at 1:26 PM, Yonik Seeley wrote:
I wouldn't necessarily link FieldType.isPolyField() to the idea of a
poly value source... they are two different things.
Yep. The word Poly is overloaded here to mean multiple ValueSources, but it
isn't necessarily tied to there being a poly
On Dec 10, 2009, at 1:44 PM, Grant Ingersoll wrote:
On Dec 10, 2009, at 1:26 PM, Yonik Seeley wrote:
I wouldn't necessarily link FieldType.isPolyField() to the idea of a
poly value source... they are two different things.
Yep. The word Poly is overloaded here to mean multiple
On Thu, Dec 10, 2009 at 1:44 PM, Grant Ingersoll gsing...@apache.org wrote:
[...]
Maybe, there are tradeoffs though.
Let's get concrete and look at the VectorDistanceFunction (dist()). It can
currently take in an even number of ValueSource instances
Geo will be the dominant use of points by
On Dec 10, 2009, at 1:54 PM, Grant Ingersoll wrote:
D'oh, I see another way of doing this, namely the Distance functions only
work with points.
Namely, the second case above becomes:
dist(2, point1, point(x1, y1));
So, I went this route and I think it actually plays out quite nice (in
