+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> 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> >>> 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> 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> >>>>> 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> 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> 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 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. >>>>>>>> >>>>>>>>
