Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-24 Thread Ariel Weisberg
Hi, SGTM. It's not just what we return though it's also supporting UPSERT for RMR updates? Because our transactions are one shot I don't think you could do that because the statement that does INSERT IF NOT EXIST would not generate a row that is visible to a later UPDATE statement in the same t

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-24 Thread Caleb Rackliffe
It sounds like the best course of action for now would be to keep the current behavior. However, we might want to fold this into CASSANDRA-18107 as a specific concern around what we return when an explicit SELECT isn't present in the transaction. i.e. For any update, we'll have something like (co

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-24 Thread Ariel Weisberg
Hi, I think the current behavior maps to SQL more than CQL. In SQL an update doesn't generate an error if the row to be updating doesn't exist it just return 0 rows updated. If someone wanted an upsert or increment behavior in their transaction could they accomplish it with the current transa

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-21 Thread Benjamin Lerer
> > Doesn’t an UPDATE statement creates a row if the partition key does not > exist? Things are more tricky that what the documentation is letting people believe. Internally, UPDATE does not really create a row. It creates a set of updates for a row. At the CQL level it looks like a row exists b

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-21 Thread Jon Haddad
Seems to me that this should use the same behavior as a counter unless IF EXISTS is supplied. I can see a solid argument for failing though, if the argument is that only counters behave that way, vs increment / decrement. On Fri, Jun 21, 2024 at 4:32 PM Josh McKenzie wrote: > What about abort

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-21 Thread Josh McKenzie
What about aborting the transaction / raising an exception if you try and do an incremental operator against a non-existent PK? The reasonable inferred intent of the user is to change a value that's expected to be there, so if it's not there it's an error case right? Otherwise you'd append "IF

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-20 Thread Caleb Rackliffe
It does, but the primary reason it does is that it is setting a value, not incrementing one. When we’re setting a value, we don’t care what was there before. Incrementing a value is not possible in a non-transitional update, hence this thread…On Jun 20, 2024, at 5:17 PM, Bernardo Botella wrote:Do

Re: [DISCUSS] Increments on non-existent rows in Accord

2024-06-20 Thread Bernardo Botella
Doesn’t an UPDATE statement creates a row if the partition key does not exist? That’s also confirmed by the official Cassandra documentation here : ”Unlike in SQL, UPDATE does not check the prior existence of the ro

[DISCUSS] Increments on non-existent rows in Accord

2024-06-20 Thread Caleb Rackliffe
We had a bug report a while back from Luis E Fernandez and team in CASSANDRA-18988 around the behavior of increments/decrements on numeric fields for non-existent rows. Consider the following, wich can be run on the cep-15-accord branch: CREA