> Like I mentioned in my earlier email, the if/abort syntax throwing an
> exception would, at least as described, limit useful data returned to the
> client
Right, I agree. I think this is orthogonal to the other syntax questions. I
think it is also preferable not to mix success/failure with da
> is there a subset … that could be implemented as an initial version and then
> grown over time to include more powerful features?
This is what I would like to aim for, but it’s hard as we probably don’t agree
in what direction the feature will develop.
My view is that we are more likely than
What on earth does MIXED mean?
I agree with the sentiment we should minimise surprise, but everyone is
surprised differently so it becomes a sort of pointless rubrik, everyone
claiming it supports their view. I think it is only useful in cases where there
is clear agreement that something is su
On Mon, Jun 13, 2022 at 1:57 PM Blake Eggleston
wrote:
> I prefer an approach that supports an accurate mental model of what’s
> happening behind the scenes. I think that should be a design priority for
> the syntax. We’ll be able to build things on top of accord, but the core
> multi-key cas ope
I'm coming to this thread fresh and admittedly I'm still trying to catch up
and wrap my head around it. I think it's already been called out, but what
looked superficially simple at the beginning of the thread has quickly
become something that I'm having to take notes on to make sure I understand
t
> Don’t call these transactions, the term implies things accord doesn’t do.
> Maybe call them CAS BATCH, and terminate them with APPLY or APPLY IF.
The condition is optional, so CAS is not accurate. These are also definitely
transactions, they are only non-interactive - transactions in SQL are a
Regarding modeling syntax after SQL... that approach has pros and cons.
Supporting an SQL like syntax implies capabilities that we can’t provide, so
you’re delivering something that looks familiar, but behaves differently, which
doesn’t help us with usability.
I prefer an approach that supports
Does the IF <...> ABORT simplify reasoning though? If you restrict it to only
dealing with the most recent row it would, but referencing the name implies
you’d be able to include references from other operations, in which case you’d
have the same problem.
> return instead an exception if the tr
Benedict,
I'm really excited about this feature. I've been observing this
conversation for a while now, and I"m happy to add some thoughts.
We must balance the fact we cannot afford to do everything (yet), against
> the need to make sure what we do is reasonably intuitive (to both CQL and
> SQL
I believe that is a MySQL specific concept. This is one problem with mimicking
SQL – it’s not one thing!
In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL value
submitted to a Boolean operator yields UNKNOWN.
IF (X) THEN Y does not run Y if X is UNKNOWN;
IF (X) THEN Y ELSE
> IF (X) THEN
> ROLLBACK
> RETURN (ERRCODE)
> END IF
>
> or
>
> IF (X) THEN RAISERROR
>
> So, that is in essence the question we are currently asking: do
> we want to have a more LWT-like approach (and if so, how do we
> address this complexity for the user), or do we want a more
> SQL-l
11 matches
Mail list logo
