Search code examples
solrcassandradatastaxdatastax-enterprise

Multiple OR frange in DSE Solr

I have to dates, originalArrivalEta and realArrivalEta, and I would like to do a Solr search based on the difference between these dates.

The main problem is that my time range is not continuous, it is spliced. So, for example, I want a range between 3 and 5 days for both later and sooner dates.

I know can do:

fq: {!frange l=-172800000 u=172800000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta)

But, since fq is always concatenating I cannot do:

fq: {!frange l=-172800000 u=-86400000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta)
fq: {!frange l=86400000 u=172800000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta)

I have also tried to do a pure negative by basically trying to remove the "hole" in the middle of the range that I am not interested in:

fq: {!frange l=-172800000 u=172800000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta)
fq: -{!frange l=-86400000 u=86400000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta)

I tried with NOT and OR, but neither seem to work.

I have also tried to use a fl by defining it: 

fl: timediff:ms(originalArrivalEta, realArrivalEta)

But I don't seem to be able to filter by it. And I am not sure my current technology stack allow me to do this anyway, since I am currently using Cassandra DSE 5.1 engine, that uses Solr 6.0.

Is there a way to use multiple frange that are not concatenated? Is there some kind of way I can put this in the q like:

q: ( {!frange l=-172800000 u=-86400000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta) OR {!frange l=86400000 u=172800000 incu=true incl=true}ms(originalArrivalEta, realArrivalEta) )

I know performance will be likely impacted, but if there is no other way to do it, then better slow than never.

Thanks for the help!

Solution

  • You can use _query_ to run other queries inline - that could work.

    In this case you do however have the abs function, which would allow you to only define one range.

    For better performance I'd suggest indexing this field as well, and populating it with an update chain - that way you can use any query syntax without having to invoke functions.