* 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
