I expect LET to behave like SELECT, and I don’t expect this work to modify the behaviour of normal CQL expressions. Do you think there is something wrong or inconsistent about the behaviours you mention?
Static columns are a bit weird, but at the very least the following would permit the user to reliably obtain a static value, if it exists: LET x = some_static_column FROM table WHERE partitionKey = someKey LIMIT 1 This could be mixed with a clustering key query LET y = some_regular_column FROM table WHERE partitionKey = someKey AND clusteringKey = someOtherKey From: Konstantin Osipov <kos...@scylladb.com> Date: Wednesday, 15 June 2022 at 14:04 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: CEP-15 multi key transaction syntax * bened...@apache.org <bened...@apache.org> [22/06/15 10:00]: > It sounds like we’re zeroing in on a solution. > > To draw attention back to Jon’s email, I think the last open question at this > point is the scope of identifiers declared by LET, and how we handle name > clashes with table columns in an UPDATE. > > I think we have basically two options: > > 1. Require LET for all input parameters to an assignment in UPDATE > 2. Add some additional syntax to local variables to identify them, e.g. > <variable> I'm curious, regardless of the syntax you choose, will LET or SELECT return the static row if there is no match for the clustering key, or return NULL row? I am asking because SELECT currently does not return any rows if there is no clustering key matching the WHERE clause, but a conditional UPDATE chooses the static row to check conditions instead, if it's present. -- Konstantin Osipov, Moscow, Russia
