On Dec 7, 2009, at 6:13 PM, Chris Hostetter wrote: > : I'm not sure if you worry about it. But I'd argue it isn't natural > : anyway. You would do the following instead, which is how any address > : book I've ever seen works: > : <field name="home" type="LatLonFT"/> > : <field name="work" type="LatLonFT"/> > > ...the home vs work distinction was arbitrary. the point is what if > i want to support an arbitrary number of distinct values in a PolyField?
This is the beauty of Yonik's addition of getFieldQuery() to the FieldType. The FieldType will be aware of the arbitrariness. Furthermore, it can "reflect" on the index itself via IndexReader.getFieldNames() to determine the number of Fields that actually exist if it has to. However, my guess is that in practice in most situations the FieldType author/user will have the info it needs. Still, I think we can also evolve if we need to. > ... with your approach any attempt to search for people near X would > require me to search for work near X or home near X ... which is analogous > to oneof hte main purposes of multivalued fields: so i don't have to > uniquely name every Field instance. Sure, but would you really ever model multiple locations like that in the same field? I don't think in practice that you would, so I think it is a bit of a red herring. Perhaps there is a different use case that better demonstrates it? > I might have a thousand unique > (but unamed) locations that i want to associate with a document, and i > want to search for documents with a location near X ... likewise i might > have thousands unique polygons associated with a document and i want to > search for documents where one or more polygons overlap with an input > polygon (ie: island nations overlapping with the flight path of an > airplane). I don't think this implementation precludes that. The FunctionQueries only operating on a single valued field does, however. Setting that aside, we could write a Query that does what you want, I think. > > The question is: how can/would PolyFields deal with input like this? .. > we've discussed cardniality in the number of fields produced by a single > input value, but we haven't really discussed cardinality in the number of > input values. I'm not sure that it does, but I don't know that it needs to just yet. This might be where an R-Tree implementation comes in handy, but I'll leave it to the geo-experts to discuss more. I also am not sure how the PolyField case is any different than the dynamic field case. Either way, something needs to know the names of the fields that were created. > > : So, maybe the FT can explicitly prohibit multivalued? But, I suppose > : you could do the position thing, too. This could be achieved through a > : new SpanQuery pretty easily: SpanPositionQuery that takes in a term and > : a specific position. Trivial to write, I think, just not sure if it is > : generally useful. Although, I must say I've been noodling around with > > The problem is how do you let the PolyField specify the position when > indexing? the last API i saw fleshed out in this discussion didn't give > the PolyField any information about how many input values were in any > given doc, it just allowed PolyFields to be String=>Field[] black boxes > (as opposed to the String=>Field[] black box FieldTYpes must currently > be). > > We can't assume even basic "lastPostion+1" type logic for these > polyfields, because differnet input values might produce Filed arrays > containing different quantities of fields, with differnet names. if a > CartiesienPolyFieldType can get away with only using the grid_level1 and > grid_level2 fields for one input value, but other input values require > using grid_level2, grid_level2, and grid_level3, then simple position > increments aren't enough if a document has multiple values (some of which > need 2 different Field names, and others that need 3) That's not how the Cartesian Field stuff works, but I think I see what you are getting at and I would say I'm going to explicitly punt on that right now. Ultimately, I think when such a case comes up, the FieldType needs to be configured to be able to determine this information. -Grant
