lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: SOLR-1131 - Multiple Fields per Field Type
Date Sat, 28 Nov 2009 08:45:38 GMT
What about rather than conflating field types for creating multiple  
fields, use update processors to do the this expansion instead?


On Nov 26, 2009, at 10:04 AM, Grant Ingersoll wrote:

> On Nov 25, 2009, at 8:24 PM, Chris Hostetter wrote:
>> I'm having a hard time wrapping my head arround this entire  
>> concept ... i
>> know part of my problem is that your example use case seems somewhat
>> nonsensical...
>> : As a simple proof of concept, imagine that I define a new FieldType
>> : called PlusMinusIntFieldType that extends IntField.  This FieldType
>> : takes in an int value and outputs two Fields: one with the original
>> : value and one with the negative of the value.
>> 	...
>> : OK, on the search side is where it gets tricky.  The whole point  
>> of this
>> : exercise is that the details are hidden from the user in the  
>> generic
>> : case.  Thus, a query of plusMinus:5 should automatically expand to
>> : (plusMinus__0:5 OR plusMinus__1:-5).  Of course, an expert user  
>> should
>> ...nothing could match plusMinus__0:5 that didn't also match
>> plusMinus__1:-5, so i don't really understand what the point of  
>> using the
>> field expansion for a use case like this would be ... and that's  
>> making it
>> hard for me to try and understand how this sort of system
>> could/should/would be used at query time.
> Kind of, if a user just inputs plusMinus:5, then sure, but they may  
> also want to just search the negative portion.  More importantly,  
> though, they may have a QParser or some other component that can  
> appropriately select one of the fields w/o the user knowing.
>> perhaps a more realistic example would be helpful?
>> ...or even some differnet simple and contrived examples that  
>> demonstrate
>> how this could be usefull in a way that isn't possible with a single
>> field.
> OK, a more concrete example is spatial.  A user will want to index a  
> point as a lat lon.   So, they index:  <field name="latLon">49, -79</ 
> field>.
> The implementation of how this gets indexed can be done in several  
> ways.  For starters, it can be represented as a single field using  
> Geohash or even just as a string (even if that isn't useful for  
> much).  We don't need S-1131 for that at all.  Next, they may just  
> want to represent it as a two fields:  one for the lat and one for  
> the long.  Again, not super hard to do now, but it requires the user  
> to set it up, whereas with a LatLonFieldType, this would be hidden  
> from them.  Finally, consider the cartesian tier case.  In this  
> case, a single lat lon point could be mapped to a whole slew of  
> tiers, where each tier is like a zoom level on a map application  
> (like Google Maps).  Here, we could have a CartesianTierFieldType,  
> that takes in the lower and upper bounds of the tiers to represent,  
> i.e. tier 4 through 17, and this would output 13 different  
> fields.    Local Solr currently handles this through dynamic fields  
> and user level knowledge of the magic fields used.
> For this case, there are several different search patterns:
> 1. The user may know the tier they want to search at and thus input  
> tier and a zoom level.
> 2. User invokes a QParser to build a bounding box (see

>  and the Parser is responsible for creating a filter that chooses  
> the most appropriate tier to search against.  So, the user might  
> just say:  {!tier lat=X lon=Y dist=10} and it will pick the most  
> appropriate tier, whereas putting in dist=50 would likely pick a  
> different tier.
> Does that help?
> BTW, all of this is tracked via SOLR-773.

View raw message