While I think this is a good idea for smaller data sets, it just isn't feasible for larger data sets that require indices. Having every combination of columns as indices is just hell for the RDBMS. When you are faceting with a large dataset, it's better to use something like ElasticSearch or Sphinx.
I don't think anyone was implying that you would expose this for every combination of columns, only the ones you were allowing people to query on. Presumably, you've indexed the fields you want people to be able to scope results to.
Nice. I've built something very similar in my current app. In my app it's called `SearchModel` and descendants live within the `app/models` dir. I include some modules from `ActiveModel` to make it act as a regular db-backed model, which allows me to use it with `form_for`.
Comments
While I think this is a good idea for smaller data sets, it just isn't feasible for larger data sets that require indices. Having every combination of columns as indices is just hell for the RDBMS. When you are faceting with a large dataset, it's better to use something like ElasticSearch or Sphinx.
I don't think anyone was implying that you would expose this for every combination of columns, only the ones you were allowing people to query on. Presumably, you've indexed the fields you want people to be able to scope results to.
Nice. I've built something very similar in my current app. In my app it's called `SearchModel` and descendants live within the `app/models` dir. I include some modules from `ActiveModel` to make it act as a regular db-backed model, which allows me to use it with `form_for`.
Ah, that's neat. I usually just build these forms without the Rails helpers, using something like:
Which works out nicely, since the method defaults to 'GET' and the action defaults to the current path.It'll do too, but I think it's nice to abstract the http-layer completely away from the view.
In case you want to replicate, I believe the relevant part is simply adding this to the base class:
And then add `attr_reader` for each field.Differences with https://github.com/plataformatec/has_scope?
Author here. Probably a matter of preference, to be honest. has_scope never really made much sense to me.
If we're checking boxes, two features that Filterer has and has_scope doesn't are:
- results ordering
- pagination (although most folks will already be using kaminari or will_paginate)
It's basically a service object specifically built for scopes with its own DSL. I like it :)
Correct me if I am wrong.