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

Weird behaviour using 'each' on Ransack results #340

Closed
ronald05arias opened this issue Feb 21, 2014 · 5 comments
Closed

Weird behaviour using 'each' on Ransack results #340

ronald05arias opened this issue Feb 21, 2014 · 5 comments

Comments

@ronald05arias
Copy link

I am experiencing a wrong behaviour on Ransack results, when using different fields to search for.

An example above:

  • Having 2 fields with potencially the same data ('email' and 'social_email' for example)
  • Looking for q[email_or_social_email_cont]
  • Querying in the controller res = Model.search(params[:q]).results

I am getting the proper results (1 in this case), also res.count is the proper count (1 in this case), but when running the 'each' method on the collection, I got duplicates.

Example:

  1. User {:email => 'user@email.com', :social_email => 'user@email.com'}
  2. u = User.search(email_or_social_email_cont: 'user@email.com').results
  3. u.count equals to 1
  4. u.each { |u1| puts u1.email } prints the email 2 times.

I have to run res.uniq.each to make it work properly.

Is there something "hacky" being done in the search method?
Thanks.

@graywh
Copy link

graywh commented Feb 25, 2014

Check the SQL being used. The #count method is probably counting the distinct id's of User. The #length of the result will be 2.

@ronald05arias
Copy link
Author

Right. I understand that @graywh. Indeed, the SQL is counting DISTINCT users. But the thing is, shouldn't Ransack be retrieving unique results already?

Given that is a search what you are performing.

@jonatack
Copy link
Contributor

Hi @ronald05arias, would your issue be solved by point 3 under Simple Mode in the README instructions?

@ronald05arias
Copy link
Author

It does @jonatack ! Thanks for pointing it out.
Any chance you know why isn't this the default behaviour? (Apart of the one described in the ReadMe).
Best Regards.

@jonatack
Copy link
Contributor

You're welcome :) I reckon @ernie opted for distinct: true to be optional because otherwise the SQL is invalid in the (frequent) case mentioned in the README.

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

No branches or pull requests

3 participants