somewhere that a value is expected (the right-hand side of WHERE criteria, or insert()/update() values)
and in these situations, clone() was working correctly because it doesn't clone values (which are typically immutable, though I suppose it's technically possible for someone to mutate a sql() literal).
But right after that, the docs give an example where sql() is used in a higher-level context -- not just as a value, but as the entire WHERE expression. It is in these cases that it was throwing the error, and this is what was fixed in this pull request.
I should probably update the docs to explicitly allow sql() in more contexts and should think a little harder about whether we really need/want that functionality in the big 3.x refactor (which may never happen, at this rate).
This fixes #118, with a couple of tests to protect against regressions.
The docs state that sql() should be used:
and in these situations,
clone()was working correctly because it doesn't clone values (which are typically immutable, though I suppose it's technically possible for someone to mutate asql()literal).But right after that, the docs give an example where
sql()is used in a higher-level context -- not just as a value, but as the entire WHERE expression. It is in these cases that it was throwing the error, and this is what was fixed in this pull request.I should probably update the docs to explicitly allow
sql()in more contexts and should think a little harder about whether we really need/want that functionality in the big 3.x refactor (which may never happen, at this rate).