Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combining fulltext_search with other criteria? #12

Open
eimermusic opened this issue Apr 18, 2013 · 7 comments
Open

Combining fulltext_search with other criteria? #12

eimermusic opened this issue Apr 18, 2013 · 7 comments

Comments

@eimermusic
Copy link

I don't index large articles where relevance is the only concern in search results. Therefore I eventually reach a point where I need to order and/or filter the results using other mongoid criteria.

For example finding Articles matching the fulltext term "foo" but also was published in the last week. Or displaying the results in a table and wanting to sort (asc and desc) on different table columns like title, author or published timestamp.

I haven't figured out if or how to work these things into the filters options in mongoid_fulltext. Maybe it is possible. But they seem to require filters that can be "rendered" and index-time.

Limiting with other criteria when calling .fulltext_search() is possible and do work... sort of. They just throw exceptions whenever something is actually filtered and an id is not found. (Thanks to Mongoid 3's new behavior).

So, finally a question or two

Would it be possible for mongoid_fulltext to not use find(foo) but instead use .where('_id' => foo) without breaking other behaviors?

@eimermusic
Copy link
Author

Thought I'd post what I do currently... and fear it breaking in any minor update :)

  def self.instantiate_mapreduce_results(results, options)
    ids = results.map { |result| result[:id] }.compact
    where(:_id.in => ids)
  end

I override the method that instantiates the results and insert a simple criteria. I can do it this way because I don't search multiple models and don't use the scores in this case.

What this effectively ends up looking like to Mongoid is:

  Article.all_in(:tags => ["hello"]).where(:_id.in =>[...]).order_by(:created_at.desc)

This is really useful to me because it gives me the power of the ngram text searching while staying compatible with "other basic filtering options". Keeping the required relevance and the maximum number of results reasonably high makes those not an issue... so far at least.

Could something like this be made a more supported option? Perhaps allowing users to set a lambda or name of a method to call as an alternative to the built-in instantiate_mapreduce_results?

@msaspence
Copy link

+1 I also have this problem, for me it is documents that have been archived and so I don't want appearing in the results.

I can verify that this patch works for me, but scares the beejesus out of me so I've opted to set raise_not_found_error to false. It does creates a little more work for me in my controller (I have to raise DocumentNotFound myself when result of find is nil).

@sbauch
Copy link

sbauch commented Feb 18, 2014

Did either of you come up with a better solution here?

I need to do something similar but with related docs, i.e. fulltext search of blog posts with author_id == xyz

@eimermusic
Copy link
Author

I eventually realized that I should use a different text indexing/search method altogether. For my data I found a better fit in the gem "mongoid_search". It is not as advanced as mongoid_fulltext but fit my more simplistic needs better.

@sbauch
Copy link

sbauch commented Feb 19, 2014

thanks @eimermusic, seems as if that gem is a better fit for my needs as well.

The ability to chain the full text search with other criteria was key

@Mohakjuneja
Copy link

Is there an update on this feature request?

@dblock
Copy link
Contributor

dblock commented Feb 11, 2017

Nobody is working on it, please contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants