Modifying the behaviour for IF clauses is a major breaking change that could
have disastrous effects for customers, that would be very hard to audit
applications for on upgrade, so I think that option is a non-starter.
I would support an effort to introduce a new session mode where we make
ours
The transaction syntax is sufficiently different it’s perhaps ok to define our
null behaviour differently. Perhaps eventually deprecating LWTs can be our
migration story for consistent null handling, if it’s the only place that
treats nulls this way today. We should clearly document this though
SAI does not support null either.
One main motivation for this thread is for accords IF clause; should it act
more like where or CAS IF?
I’m of the stance it would be hard to reject null as we might not know it’s
null till we do and LET clause, so null in operation becomes false is my stance
S
In fuzz testing I have found some differences between `WHERE` and `IF` clauses
that want to get feedback from the broader community.
If you try to query with a `null` we will reject it
```
@Test
public void test() throws IOException
{
try (Cluster cluster = Cluster.build(1).start())
