Searching for 'marco' finds too much about scoped_search HOT 10 OPEN

You can define the following:
scoped_search :on => [:id, :name, :content]
scoped_search :on => [:created_at, :updated_at], :only_explicit => true

from scoped_search.

Is marco march in another language?

I just had a try and english and german returned the same results:

irb(main):007:0> Date.parse 'march'
=> #<Date: 2013-03-01 ((2456353j,0s,0n),+0s,2299161j)>
irb(main):008:0> Date.parse 'marsch'
=> #<Date: 2013-03-01 ((2456353j,0s,0n),+0s,2299161j)>

If that's the case it might just be possible to disable those other
languages if you don't want them parsed? Unsure if that is a good fix or
not...

On 10/04/13 22:14, abenari wrote:

You can define the following:
scoped_search :on => [:id, :name, :content]
scoped_search :on => [:created_at, :updated_at], :only_explicit => true

—
Reply to this email directly or view it on GitHub
#51 (comment).

from scoped_search.

It happens as soon as you use mar, apr or even with a number...:

1.9.3p392 :006 > DateTime.parse 'aprilia'
 => #<DateTime: 2013-04-01T00:00:00+00:00 ((2456384j,0s,0n),+0s,2299161j)>
1.9.3p392 :007 > DateTime.parse '20001'
 => #<DateTime: 2020-01-01T00:00:00+00:00 ((2458850j,0s,0n),+0s,2299161j)>

from scoped_search.

Using the definition mentioned by @abenari works. But I think this needs a change anyway as DateTime.parse will always return strange values.

from scoped_search.

If you keep the date columns only explicit, it also give you great flexibility in searching for dates

from scoped_search.

Maybe we should only attempt DateTime.parse if the query word starts with a digit?

from scoped_search.

I seem to recall some of the tests explicitly testing that it worked
with things like "Today" and "Yesterday". So your idea is possible,
would just require removing that functionality.

On 15/04/13 15:05, Willem van Bergen wrote:

Maybe we should only attempt |DateTime.parse| if the query word starts
with a digit?

—
Reply to this email directly or view it on GitHub
#51 (comment).

from scoped_search.

The date functionality also has timezone issues: #43. Not sure what the best way forward is to make this more robust.

from scoped_search.

@brocktimus Yes, or we handle Today and Yesterday explicitly.What other values do we want to support?

from scoped_search.

You're right. Today and Yesterday are handled explicitly. I'm not sure what values we'd like to support, my main use for this library is the really basic text searching stuff. I'm also normally super explicit, but that is more me than an average user.

I think the behaviour at the moment is a bit unintuitive. If anything I would expect 'March' to span all of March. Does it ever work that well as a search library for dates or times when it isn't explicitly mentioned? I would be tempted to do a simple regex like /\d[:- ]\d/ to check it has at least two digits and a separator before parsing it into DateTime.parse unless the field is explicitly mentioned.

Somewhat unrelated but should we be using Time.zone.parse instead of DateTime.parse ?

from scoped_search.