where ignores keys if values are empty hashes

[giorgian]

In version 3.2.6:

User.where(:token => {}).first

    User Load (0.3ms)  SELECT "users".* FROM "users" LIMIT 1

This may lead to trouble if I check for, say, params[:token] to exist but not for it to be nonblank.

[mauricio]

I don't get it. What would you want it to do?

[giorgian]

Actually, I have two different issues with the way this currently works.

My first concern is that, as a RoR user, I tend to trust it very much and to believe that it'll protect me when it comes to injections and other nasty things; for that reason, I'd like AR never to accept an hash coming from params, unless explicitly told to. That, though, is out of the scope of this issue.
Users are often encouraged to do things like Something.where(:id => params[:id]).first. What I'd expect, if a bad param is passed, is for this query to return nothing, not to return what the the first object in the table happens to be.

So, returning an empty relation seems to me the right thing to do in this case.

My other concern is about semantics: the expression :some_column => {} is interpreted, as I understand it, roughly as: do nothing for the table some_column. When I see it, though, I'm naively led to interpret it as: 'some_column = ?', {}, which evaluates to :some_column => nil.

So, interpreting it as :some_column => nil is another possibility; it's also what happens for :some_column => [].

Any of these two alternatives would, IMO, be preferable to the current behavior.

[dmathieu]

I pushed patch about this in #6971