Ignore empty values and expressions to prevent syntax error

[huandu]

This PR is to address the issue that builders will generate bad SQL statements if empty values and/or expressions are provided.

For instance, if we build SQL like following, we will get a SQL statement with syntax error.

// Intentionally let values be nil.
var values []int

sb := Select("c").From("t")
sb.Where(sb.In("c", ...Flatten(values)))

print(sb) // SELECT c FROM t WHERE c IN ()

In this PR, if there is no values or expressions provided in Cond.IN/Cond.NotIn/Cond.Some/Cond.All/Cond.Any/Cond.And/Cond.Or, the condition will be ignored completely. Thus, the case above will print SELECT c FROM t with this PR.

It's a better solution to address the same issue mentioned in PR #188. cc @ErikBooijMB

[coveralls]

coverage: 96.743% (-0.1%) from 96.879%
when pulling 06070c6 on feature/prevent-syntax-error-with-zero-values
into b0b0b02 on master.

[ErikBooijMB]

Sorry, totally missed this PR in in my notification. Really appreciate your effort to jump on this and fix it in a way that's cleaner than my approach was.

Not 100% sure that silently ignoring these conditions with no values is right approach. For NOT IN I think that's fine, and yields the expected result, but for IN/ANY/SOME/ALL, this may do the opposite of what a user expected.

[Sora233]

sqlbuilder.List好像没有同步修改

[huandu]

@Sora233 嗯，下个版本补一下

[rodionovv]

Hello.

I want to share my thoughts on suggestion made by @ErikBooijMB earlier. I fully agree that silent drop of IN query is wrong and always FALSE statement must remain in the query. But i think the same logic must apply to NOT IN operator. It is an always TRUE statement and can be only sometimes dropped without affecting result of query. In many cases dropping it will also affect the result. For example in an OR query if all other statements are FALSE the always TRUE statement will make full query TRUE but now its just dropped and query remains FALSE. So i think its better not to drop it but replace with 0 = 0. This way in many cases it wont affect anything but in some cases query will remain correct.

Also its probably more predictable for user that almost same operators behave in the almost same way. if something is always FALSE its replaced with a FALSE statement and the same with TRUE. c.NotIn("$a") and c.Not(c.In("$a")) statements produce different SQL query which very misleading from my view.

What do you think about it?

[huandu]

@rodionovv Sorry for late response. I missed your comment. If you have any feedback on a closed issue, you can either re-open it or create a new issue so that I can track it better.

But i think the same logic must apply to NOT IN operator.

Agree. I should fix it as a bug.

Also its probably more predictable for user that almost same operators behave in the almost same way.

You're right. Let me know if you find more bad cases other than NotIn. I can fix them together.