Use OR between multiple ranges.

On Fri, Aug 6, 2010 at 8:52 AM, Thomas Joiner <thomas.b.joi...@gmail.com> wrote:
> This will work for a single range.  However, I may need to support multiple
> ranges, is there a way to do that?
>
> On Fri, Aug 6, 2010 at 10:49 AM, Jan Høydahl / Cominvent <
> jan....@cominvent.com> wrote:
>
>> Your use case can be solved by splitting the range into two int's:
>>
>> Document: {title: My document, from: 8000, to: 9000}
>> Query: q=title:"My" AND (from:[* TO 8500] AND to:[8500 TO *])
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> Training in Europe - www.solrtraining.com
>>
>> On 6. aug. 2010, at 17.02, Thomas Joiner wrote:
>>
>> > I need to have a field that supports ranges...for instance, you specify a
>> > range of 8000 to 9000 and if you search for 8500, it will hit.  However,
>> > when googling, I really couldn't find any resources on how to create your
>> > own field type in Solr.
>> >
>> > But from what I was able to find, the AbstractSubTypeFieldType class
>> seems
>> > like a good starting point for the type that I want to make, however that
>> > isn't in the current version of Solr that I am using (1.4.1).  So I guess
>> my
>> > question is: is Solr 3.0 ready for production?  If so, how do I get it?
>> Do I
>> > just need to checkout the code from svn and build it myself?  If so
>> should I
>> > just check out the latest, or is there a particular branch that I should
>> go
>> > with that is reliable?  If I switch to 3.0, will I need to reindex my
>> data,
>> > or has the data format not changed?
>> >
>> > And if 3.0 isn't ready for production, what would you suggest I do?  Is
>> the
>> > AbstractSubTypeFieldType such that I can backport it and use it with
>> 1.4.1,
>> > or does it use specific features of 3.0 that I would have to backport as
>> > well, in which case it would become a horribly convoluted mess where I
>> would
>> > be better off just going with 3.0.  And I guess this comes back to help
>> on
>> > finding resources about implementing custom types...it would just be more
>> > complicated if I couldn't use the AbstractSubTypeFieldType.
>> >
>> > (This is my first time posting to a mailing list, so if I have violated
>> > horribly some etiquette of mailing lists, please tell me).
>> >
>> > Regards,
>> > Thomas
>>
>>
>



-- 
Lance Norskog
goks...@gmail.com

Reply via email to