We've agreed in the past that we want to maintain compatibility and that
> all changes will be done with compatibility in mind (see
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle),
> but we haven't clarified how we make the call on when to bump to next
> major.
>
+1 to
This has come up in CASSANDRA-16844, so wanted to bring to a wider audience.
As of this moment, 3 breaking changes have been detected in 4.1 (1 of them was
merged into 4.0 as well), and how to resolve this has been talked about a lot,
so felt its best to have this conversation here. We've agre
I think in any scenario where the same cell is updated multiple times, the last
one would win. The final result for s3 in your example would be 2
> On Jun 16, 2022, at 10:31 AM, Jon Meredith wrote:
>
> The reason I brought up static columns was for cases where multiple
> statements update them
The reason I brought up static columns was for cases where multiple
statements update them and there could be ambiguity.
CREATE TABLE tbl
{
pk1 int,
ck2 int,
s3 static int,
r4 static int,
PRIMARY KEY (pk1, ck2)
}
BEGIN TRANSACTION
UPDATE tbl SET s3=1, r4=1 WHERE pk1=1 AND ck2=1;
UPDATE
I like Postgres' approach of letting you declare an exceptional condition and
failing if there is not precisely one result (though I would prefer to
differentiate between 0 row->Null and 2 rows->first row), but once you permit
coercing to NULL I think you have to then treat it like NULL and perm
Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a
little trickier. Assigning null to a column seems ok, but we should raise an
exception if they're doing math or something that expects a non-null value
> On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith
> wrote:
>
AFAICT that standard addresses server-side cursors, not the assignment of a
query result to a variable. Could you point to where it addresses variable
assignment?
Postgres has a similar concept, SELECT INTO[1], and it explicitly returns NULL
if there are no result rows, unless STRICT is specifi
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 synt
* 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 mod
* bened...@apache.org [22/06/13 17:37]:
> I believe that is a MySQL specific concept. This is one problem with
> mimicking SQL – it’s not one thing!
>
> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL value
> submitted to a Boolean operator yields UNKNOWN.
>
> IF (X) TH
10 matches
Mail list logo
