Range queries with no upper bound (Tire)


(Robin Boutros) #1

Hey,

Sorry if it's not directly an elasticsearch problem...

I'm tring to search for upcoming events.
An event has "starts_at" and "ends_at" dates. The "ends_at" date is
optional.

Upcoming events are defined like that:

ends_at is present AND ends_at > now
OR
ends_at is missing AND starts_at > now

I'm using Tire, the best I found is:

should { string "exists:ends_at AND ends_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }
should { string "missing:ends_at AND starts_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

I'm wondering if there is a way, using a query string, to do the range query without having a upper bound (1 year in this example). When I look at the Lucene doc (http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/queryparsersyntax.html#Range Searches) it does not seem possible :frowning:

Thanks!


(Shay Banon) #2

Use *, it should work.

On Tue, Mar 20, 2012 at 2:47 AM, Robin Boutros niuage@gmail.com wrote:

Hey,

Sorry if it's not directly an elasticsearch problem...

I'm tring to search for upcoming events.
An event has "starts_at" and "ends_at" dates. The "ends_at" date is
optional.

Upcoming events are defined like that:

ends_at is present AND ends_at > now
OR
ends_at is missing AND starts_at > now

I'm using Tire, the best I found is:

should { string "exists:ends_at AND ends_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

should { string "missing:ends_at AND starts_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

I'm wondering if there is a way, using a query string, to do the range query without having a upper bound (1 year in this example). When I look at the Lucene doc (http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/queryparsersyntax.html#Range Searches) it does not seem possible :frowning:

Thanks!


(Robin Boutros) #3

Thanks! but it doesn't seem to work.

Here is the ES query generated by Tire: http://jsfiddle.net/dJPxX/1/

And the error:

nested: ParseException[Cannot parse 'exists:to AND to:[2012-03-20 10:43:15 -0400 TO *]': Encountered " <RANGEIN_GOOP> "-0400 "" at line 1, column 40.\nWas expecting:\n "]" ...\n ];

On Tuesday, March 20, 2012 6:51:17 AM UTC-4, kimchy wrote:

Use *, it should work.

On Tue, Mar 20, 2012 at 2:47 AM, Robin Boutros <> wrote:

Hey,

Sorry if it's not directly an elasticsearch problem...

I'm tring to search for upcoming events.
An event has "starts_at" and "ends_at" dates. The "ends_at" date is
optional.

Upcoming events are defined like that:

ends_at is present AND ends_at > now
OR
ends_at is missing AND starts_at > now

I'm using Tire, the best I found is:

should { string "exists:ends_at AND ends_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

should { string "missing:ends_at AND starts_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

I'm wondering if there is a way, using a query string, to do the range query without having a upper bound (1 year in this example). When I look at the Lucene doc (http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/queryparsersyntax.html#Range Searches) it does not seem possible :frowning:

Thanks!


(Shay Banon) #4

I think the problem comes from the timezone in the query_string, where it
has an extra space. Try and provide it without the space? Also, you can
convert the query_string query into its counterpart query with range query
in it.

On Tue, Mar 20, 2012 at 4:44 PM, Robin Boutros niuage@gmail.com wrote:

Thanks! but it doesn't seem to work.

Here is the ES query generated by Tire: http://jsfiddle.net/dJPxX/1/

And the error:

nested: ParseException[Cannot parse 'exists:to AND to:[2012-03-20 10:43:15 -0400 TO *]': Encountered " <RANGEIN_GOOP> "-0400 "" at line 1, column 40.\nWas expecting:\n "]" ...\n ];

On Tuesday, March 20, 2012 6:51:17 AM UTC-4, kimchy wrote:

Use *, it should work.

On Tue, Mar 20, 2012 at 2:47 AM, Robin Boutros <> wrote:

Hey,

Sorry if it's not directly an elasticsearch problem...

I'm tring to search for upcoming events.
An event has "starts_at" and "ends_at" dates. The "ends_at" date is
optional.

Upcoming events are defined like that:

ends_at is present AND ends_at > now
OR
ends_at is missing AND starts_at > now

I'm using Tire, the best I found is:

should { string "exists:ends_at AND ends_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

should { string "missing:ends_at AND starts_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

I'm wondering if there is a way, using a query string, to do the range query without having a upper bound (1 year in this example). When I look at the Lucene doc (http://lucene.apache.org/**core/old_versioned_docs/**versions/3_0_0/**queryparsersyntax.html#Range http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/queryparsersyntax.html#Range Searches) it does not seem possible :frowning:

Thanks!


(Robin Boutros) #5

You're right! My date was not formatted correctly, and I didn't pay
attention to the error enough.
Basically, I commented out this line at some
point: Time::DATE_FORMATS.update :lucene => "%Y-%m-%dT%H:%M:%S%z" and
forgot to add it back when I tested your solution.

Not sure how to do what you're suggesting with Tire... Is it just nicer or
is it more performant?

Also, when I was thinking about my problem, I was wondering if it wouldn't
be better to just index the "ends_at" date as the "starts_at" date if the
ends_at date is not present... Do you have an opinion on this?

Anyways, thanks for your help, my problem is solved.

On Tuesday, March 20, 2012 4:16:52 PM UTC-4, kimchy wrote:

I think the problem comes from the timezone in the query_string, where it
has an extra space. Try and provide it without the space? Also, you can
convert the query_string query into its counterpart query with range query
in it.

On Tue, Mar 20, 2012 at 4:44 PM, Robin Boutros <> wrote:

Thanks! but it doesn't seem to work.

Here is the ES query generated by Tire: http://jsfiddle.net/dJPxX/1/

And the error:

nested: ParseException[Cannot parse 'exists:to AND to:[2012-03-20 10:43:15 -0400 TO *]': Encountered " <RANGEIN_GOOP> "-0400 "" at line 1, column 40.\nWas expecting:\n "]" ...\n ];

On Tuesday, March 20, 2012 6:51:17 AM UTC-4, kimchy wrote:

Use *, it should work.

On Tue, Mar 20, 2012 at 2:47 AM, Robin Boutros <> wrote:

Hey,

Sorry if it's not directly an elasticsearch problem...

I'm tring to search for upcoming events.
An event has "starts_at" and "ends_at" dates. The "ends_at" date is
optional.

Upcoming events are defined like that:

ends_at is present AND ends_at > now
OR
ends_at is missing AND starts_at > now

I'm using Tire, the best I found is:

should { string "exists:ends_at AND ends_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

should { string "missing:ends_at AND starts_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]" }

I'm wondering if there is a way, using a query string, to do the range query without having a upper bound (1 year in this example). When I look at the Lucene doc (http://lucene.apache.org/**core/old_versioned_docs/**versions/3_0_0/**queryparsersyntax.html#Range http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/queryparsersyntax.html#Range Searches) it does not seem possible :frowning:

Thanks!


(Shay Banon) #6

On Tue, Mar 20, 2012 at 10:37 PM, Robin Boutros niuage@gmail.com wrote:

You're right! My date was not formatted correctly, and I didn't pay
attention to the error enough.
Basically, I commented out this line at some
point: Time::DATE_FORMATS.update :lucene => "%Y-%m-%dT%H:%M:%S%z" and
forgot to add it back when I tested your solution.

Not sure how to do what you're suggesting with Tire... Is it just nicer or
is it more performant?

You mean explicit range query? It just usually simpler to build the query
then constructing the query string syntax.

Also, when I was thinking about my problem, I was wondering if it wouldn't
be better to just index the "ends_at" date as the "starts_at" date if the
ends_at date is not present... Do you have an opinion on this?

So you can get away with the missing part? Not sure I follow...

Anyways, thanks for your help, my problem is solved.

On Tuesday, March 20, 2012 4:16:52 PM UTC-4, kimchy wrote:

I think the problem comes from the timezone in the query_string, where it
has an extra space. Try and provide it without the space? Also, you can
convert the query_string query into its counterpart query with range query
in it.

On Tue, Mar 20, 2012 at 4:44 PM, Robin Boutros <> wrote:

Thanks! but it doesn't seem to work.

Here is the ES query generated by Tire: http://jsfiddle.net/**dJPxX/1/http://jsfiddle.net/dJPxX/1/

And the error:

nested: ParseException[Cannot parse 'exists:to AND to:[2012-03-20 10:43:15 -0400 TO *]': Encountered " <RANGEIN_GOOP> "-0400 "" at line 1, column 40.\nWas expecting:\n "]" ...\n ];

On Tuesday, March 20, 2012 6:51:17 AM UTC-4, kimchy wrote:

Use *, it should work.

On Tue, Mar 20, 2012 at 2:47 AM, Robin Boutros <> wrote:

Hey,

Sorry if it's not directly an elasticsearch problem...

I'm tring to search for upcoming events.
An event has "starts_at" and "ends_at" dates. The "ends_at" date is
optional.

Upcoming events are defined like that:

ends_at is present AND ends_at > now
OR
ends_at is missing AND starts_at > now

I'm using Tire, the best I found is:

should { string "exists:ends_at AND ends_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]****" }

should { string "missing:ends_at AND starts_at:[#{Time.now.to_s(:lucene)} TO #{1.year.since.to_s(:lucene)}]****" }

I'm wondering if there is a way, using a query string, to do the range query without having a upper bound (1 year in this example). When I look at the Lucene doc (http://lucene.apache.org/core/old_versioned_docs/**versions/**3_0_0/**queryparsersyntax.html#**Range http://lucene.apache.org/core/old_versioned_docs/versions/3_0_0/queryparsersyntax.html#Range Searches) it does not seem possible :frowning:

Thanks!


(Robin Boutros) #7

If I index the ends_at date as the starts_at (+ X hours maybe) when it's
missing, then I can always assume the ends_date is present in my search,
and I can avoid having to use this "complexe" query. That's what I ended up
doing and it does what I want.


(system) #8