You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 30, 2022. It is now read-only.
Well, the left side is a literal, I'm not complaining about that, the rest is not. Are there good cases when '== nil' should be translated as '= NULL' rather than 'IS NULL'? I can't think of any, since NULL is not considered a value, but maybe I'm missing something. I'm using this in a 'having' on a computed attribute, unless something changed more recently only literals work there.
You shouldn't be using a literal unless you have no choice. Squeel tries to make fewer assumptions about what you're up to when you have a literal. I'm just giving the rationale for what exists right now -- as I no longer maintain the library, I'll leave it up to current maintainers to decide whether they want to change/maintain that behavior.
I don't think I have a choice in this case, I tried with a stub and it puts a table name in front of it. Which doesn't work for computed attributes. Is there a way to avoid that other than use a literal? I don't think in the case of nil there's any extra assumption except that you want to test for NULL, which I think needs to always be done with IS.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If I have a condition in 'where' or 'having' that says
Squeel translates it nicely into
but if I have a literal instead
that's translated into
which of course doesn't work right.
The text was updated successfully, but these errors were encountered: