I see what you mean. We have the EXISTS/NOT EXISTS condition for explicitly checking for the existence of a row. One thing the old syntax did is how it handled references to columns that don't exist. Previously, if any column reference didn't resolve, the update wouldn't apply. With the new syntax, if we want to be able to use multiple branches, that's going to be more difficult, since taking the 'ELSE' path may not make sense from an application perspective. So returning an exception in that case might be the right thing to do
> On Jun 15, 2022, at 2:18 PM, Konstantin Osipov <kostja.osi...@gmail.com> > wrote: > > * bened...@apache.org <bened...@apache.org> [22/06/16 00:00]: >> First some history: static rows are an efficiency sop to those >> who migrated from the historical wide row world, where you could >> have “global” partition state fetched with every query, and to >> support the deprecation of thrift and its horrible data model >> something needed to give – static rows were the result. >> >> However, is the concept generally consistent? I think so. At >> least, your example seem fine to me, and I can’t see how they >> violate the “relational model” (whatever that may be). If it >> helps, you can think of the static columns actually creating a >> second table, so that you now have two separate tables with the >> same partition key. These tables are implicitly related via a >> “full outer join” on the partition key, and you can imagine that >> you are generally querying a view of this relation. > > This is a model I haven't pondered yet. > >> In this case, you would expect the outcome you see AFAICT. If >> you have no restriction on the results, and you have no regular >> rows and one static row, you would see a single static row >> result with null regular columns (and a count of 1 row). If you >> imposed a restriction on regular columns, you would not see the >> static column as the null regular columns would not match the >> condition. >> >>> In LWT, a static row appears to exist when there is no regular row matching >>> WHERE >> >> I assume you mean the IF clause matches against a static row if >> you UPDATE tbl SET v = a WHERE p = b IF s = c. This could be an >> inconsistency, but I think it is not. Recall, UPDATE in CQL is >> not UPDATE in SQL. SQL would do nothing if the row doesn’t >> exist, whatever the IF clause might say. CQL is really >> performing UPSERT. >> >> So, what happens when the WHERE clause doesn’t match a primary >> key with UPSERT? A row is created. In this case, if you consider >> that this empty nascent row is used to join with the static >> “table” for evaluating the IF condition, to decide what you >> UPSERT, then it all makes sense – to me, anyway. >> >>> NULLs are first-class values, distinguishable from unset values >> >> Could you give an example? > > In SQL, if you FETCH into a VARIABLE and there is no matching row, > it won't quietly fill your variable with NULLs or a static cells, > and leave you wondering what to do next. FETCH will RAISE NOT > FOUND condition, a kind of exception you can handle separately. > Totally different in Cassandra where NULL is a deletion marker and > NULLs are indistinguishable from missing values. > > -- > Konstantin Osipov, Moscow, Russia
