Thanks all, going to merge those changes today!
> On Sep 2, 2022, at 5:47 AM, Josh McKenzie wrote:
>
> +1 to matching SQL. If we look at our population of users that are going to
> run into this, my intuition is that more of them will be familiar with SQL
> semantics than counters, so there's
+1 to matching SQL. If we look at our population of users that are going to run
into this, my intuition is that more of them will be familiar with SQL
semantics than counters, so there's the angle where "the more consistent
option" here is to follow SQL convention.
On Wed, Aug 31, 2022, at 12:1
The approach 2) is the one used by CQL operators.
SELECT v + 1 FROM t WHERE pk = 1; Will return null if the row exists but
the v is null.
Le mer. 31 août 2022 à 18:05, David Capwell a écrit :
> Sounds like matching SQL is the current favor, the current patch matches
> this so will leave this th
Sounds like matching SQL is the current favor, the current patch matches this
so will leave this thread open a while longer before trying to merge the patch.
> On Aug 31, 2022, at 5:07 AM, Ekaterina Dimitrova
> wrote:
>
> I am also +1 to match SQL, option 2. Also, I like Andres’ suggestion
>
I am also +1 to match SQL, option 2. Also, I like Andres’ suggestion
On Wed, 31 Aug 2022 at 7:15, Claude Warren via dev
wrote:
> I like this approach. However, in light of some of the discussions on
> view and the like perhaps the function is (column value as returned by
> select ) + 42
>
> So
I like this approach. However, in light of some of the discussions on
view and the like perhaps the function is (column value as returned by
select ) + 42
So a null counter column becomes 0 before the update calculation is applied.
Then any null can be considered null unless addressed by IfN
I think I'd prefer 2), the SQL behaviour. We could also get the convenience
of 3) by adding CQL functions such as "ifNull(column, default)" or
"zeroIfNull(column)", as it's done by other dbs. So we could do things like
"UPDATE ... SET name = zeroIfNull(name) + 42".
On Wed, 31 Aug 2022 at 04:54, Ca
Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1
(depending on the type) in our previous discussion, but for some reason
didn't bring up the SQL analog :-|
On Tue, Aug 30, 2022 at 5:38 PM Benedict wrote:
> I’m a bit torn here, as consistency with counters is important. Bu
I’m a bit torn here, as consistency with counters is important. But they are a
unique eventually consistent data type, and I am inclined to default standard
numeric types to behave as SQL does, since they write a new value rather than a
“delta”
It is far from optimal to have divergent behaviou
4.1 added the ability for LWT to support "UPDATE ... SET name = name + 42",
but we never really fleshed out with the larger community what the
semantics should be in the case where the column or row are NULL; I opened
up https://issues.apache.org/jira/browse/CASSANDRA-17857 for this issue.
As I se
10 matches
Mail list logo
