Thanks all, going to merge those changes today!
> On Sep 2, 2022, at 5:47 AM, Josh McKenzie <jmcken...@apache.org> 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 the angle where "the more consistent
> option" here is to follow SQL convention.
>
> On Wed, Aug 31, 2022, at 12:19 PM, Benjamin Lerer wrote:
>> 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 <dcapw...@apple.com
>> <mailto:dcapw...@apple.com>> a écrit :
>> 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 <e.dimitr...@gmail.com
>>> <mailto:e.dimitr...@gmail.com>> wrote:
>>>
>>> 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
>>> <dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>> 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 a null counter column becomes 0 before the update calculation is applied.
>>>
>>> Then any null can be considered null unless addressed by IfNull(), or
>>> zeroIfNull()
>>>
>>> Any operation on null returns null.
>>>
>>> I think this follows what would be expected by most users in most cases.
>>>
>>>
>>>
>>> On 31/08/2022 11:55, Andrés de la Peña wrote:
>>>> 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, Caleb Rackliffe <calebrackli...@gmail.com
>>>> <mailto:calebrackli...@gmail.com>> wrote:
>>>> 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 <bened...@apache.org
>>>> <mailto:bened...@apache.org>> wrote:
>>>> 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 behaviours, but also suboptimal
>>>> to diverge from relational algebra, and probably special casing counters
>>>> is the least bad outcome IMO.
>>>>
>>>>
>>>>> On 30 Aug 2022, at 22:52, David Capwell <dcapw...@gmail.com
>>>>> <mailto:dcapw...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>> 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
>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-17857> for this issue.
>>>>>
>>>>> As I see it there are 3 possible outcomes:
>>>>> 1) fail the query
>>>>> 2) null + 42 = null (matches SQL)
>>>>> 3) null + 42 == 0 + 42 = 42 (matches counters)
>>>>>
>>>>> In SQL you get NULL (option 2), but CQL counters treat NULL as 0 (option
>>>>> 3) meaning we already do not match SQL (though counters are not a
>>>>> standard SQL type so might not be applicable). Personally I lean towards
>>>>> option 3 as the "zero" for addition and subtraction is 0 (1 for
>>>>> multiplication and division).
>>>>>
>>>>> So looking for feedback so we can update in CASSANDRA-17857 before 4.1
>>>>> release.
