This was a special feature for a project I was working on long ago.
It provided implicit behavior for trivial value (0 or "") which were
supposed to be interpreted as NULL.
They led to `operator==` potentially being serialized as 'IS NULL'.
It makes more sense to introduce explicit helpers, e.g.
- equal_or_is_null(col, optional)
- not_equal_or_is_not_null(col, optional)
- `.from(t1, t2)` produces an unconditional join if you forget to add a condition in the .where()
sqlpp11 therefore now deprecates unconditional joins.
- more often than not, writing something like `where(name == "doe")`, you
meant to write `where(t.name == "doe")`. It is hard to find bugs when
the former expression compiles because you happen to have a variable
`name` in the current scope as well.
sqlpp11 therefore now deprecates `.where(bool)` and disallows
raw bool values boolean expression like `something and bool`
wrap bools in sqlpp::value(), if you REALLY want a bool value here
This is then equivalent to in(value_list(some_empty_vector)) and
not_in(value_list(some_empty_vector):
tab.a.in() evaluates to false
tab.a.not_in() evaluates to true
