fuzzy query dsl support + term api improvement

[plentz]

For newcomers(like me - but not just me), It's pretty hard to find out how to add support to fuzzy searchs. It would be nicer to have some api to easier archive querys with fuzzy(and maybe flt).

disclaimer: I know that Tire.search 'customers', :query => { :fuzzy => { :name => 'John' } } work, but it's pretty hard to include things like pagination, etc.

this is an initial implementation and could be improved. I also added a little improvement to the term api, which allow a option's hash parameter to be passed.

[plentz]

ps: this pull request is still missing tests. I looked at the code but didn't find where the query's tests should live. There's text_query_test.rb, range_queries_test.rb, query_string_test.rb. Could someone point me if there's some kind of pattern for queries integration tests?

[karmi]

Hi, thanks for the patches!

1/ Regarding the fuzzy query support, I'm on the fence if this should go the Tire core or contrib.

2/ The fuzzy query can, in fact, be quite easily be done with the "raw API", by passing a Hash, just as the Readme instructs. We could or maybe should support stuff like pagination better with the "raw API".

3/ Yes, every query type needs corresponding tests: unit tests to check the raw behaviour (proper encoding etc), and an integration test. The convention is to put unit tests in the test/unit/search_query_test.rb file, in a separate context, for the time being. I think we will split it into multiple files in the future. Every query type has a corresponding separate integration test file, in this case it would be called test/integration/fuzzy_queries_test.rb.

4/ The missing support for options looks like a bug. Could you add a unit/integration test demonstrating the bug and filing a separate issue?

[plentz]

1. Since elasticsearch support it out-of-the-box, I think we should support it natively too, so, +1 for core.

2. Fully agree.

3. Thanks, I will update my pull request adding the corresponding tests.

4. Actually it already support passing options, but I think it could be a better looking(and simpler) API. Today, we have to do something like this:

term :name, query

but, when you want to pass options, you have to changed it to:

term :name, { term: query, boost: 2 }

which I think it's confusing(even more for newcomers). After the change I've made, all you have to do is pass the options

term :name, query, boost: 2

[BlackdolphinMedia]

+1 for the core

[plentz]

well, I think that's it. unit + integration tests created.

[gregoriokusowski]

+1 for core

[fmeyer]

👍 for core

[rafaelsteil]

+1 for core

[cmilfont]

+1 for core

[peleteiro]

+1 for core

[andreazevedo]

+1 for core

[karmi]

@BlackdolphinMedia, @gregoriokusowski, @fmeyer, @rafaelsteil, @cmilfont, @peleteiro, @andreazevedo, I appreciate your interest in Tire! However this is not Rails, please add something meaningful to the discussion...

[karmi]

@plentz Cleaned up and merged the code, thanks! For the time being it stays in core, the structure of code fo queries must be improved.

Notice, that for "fuzzy" queries, there's a standard Lucene operator for the "query_string" type. In majority of cases, it actually makes sense to use the "text" query with the fuzziness option, as @kimchy suggested on IRC.

You can see the example in the integration test, commit 137c981.

[karmi]

@plentz, this is just a summary of what I did when splitting your commit plentz/tire@eb9992b, which combined different features/changes into one.

  # Get the changes and update from master via rebase
  git checkout -b issues/289
  git pull https://github.com/plentz/tire.git master
  git rebase master

  # Start interactive rebase of all commits not on master
  git rebase -i master

  # For eb9992b commit, mark it as "edit"
  # Now, reset the commit, but leave the changes on disk -- preparing the commit "split"
  git reset HEAD^
  # Add only the portions we want
  git add -p
  # Commit only the selected changes as a split commit
  git commit -v -c eb9992b
  # Repeat with the rest of the code, splitting the commit...
  # Continue the rebase...
  git rebase --continue
  # (We also squashed the commits)
  # Now let's check what we have prepared
  git log HEAD --oneline --not master
  # We can safely merge that into master

See these sources:

• http://book.git-scm.com/4_interactive_rebasing.html
• http://stackoverflow.com/questions/4307095/git-how-to-split-up-a-commit-buried-in-history
• http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html