Ok, so I am not a huge fan of static rows, but I disagree with your analysis.
First some history: static rows are an efficiency sop to those who migrated
from the historical wide row world, where you could have “global” partition
state fetched with every query, and to support the deprecation of
* bened...@apache.org [22/06/15 18:38]:
> I expect LET to behave like SELECT, and I don’t expect this work to modify
> the behaviour of normal CQL expressions. Do you think there is something
> wrong or inconsistent about the behaviours you mention?
>
> Static columns are a bit weird, but at
Better yet strive to maintain backward compatibility. There are very very few
occasions where backward compatibility breakage is warranted.
> On Jun 15, 2022, at 10:59 AM, bened...@apache.org wrote:
>
>
> > I agree a broader consensus beyond those on the jira ticket should be
> > sought
> I agree a broader consensus beyond those on the jira ticket should be sought
> before committing the patch that bumps a new major.
Broader consensus should be sought on any ticket that breaks backwards
compatibility – even if we already have bumped major version.
A major version bump should
>
> I'm going to jump off the email list to JIRA for this one - we've had a
> discussion ongoing about when we cut a Major vs. a Minor, what qualifies as
> an API, etc on CASSANDRA-16844 (
> https://issues.apache.org/jira/browse/CASSANDRA-16844). Expect something
> to formally hit the dev mailing
I expect LET to behave like SELECT, and I don’t expect this work to modify the
behaviour of normal CQL expressions. Do you think there is something wrong or
inconsistent about the behaviours you mention?
Static columns are a bit weird, but at the very least the following would
permit the user
* bened...@apache.org [22/06/15 10:00]:
> It sounds like we’re zeroing in on a solution.
>
> To draw attention back to Jon’s email, I think the last open question at this
> point is the scope of identifiers declared by LET, and how we handle name
> clashes with table columns in an UPDATE.
>
>
There are 3 view filtering test failures in the 8 4.1 failures which are
known offenders as being parametrized they might take long in an
overloaded systems. Once we're back to normal capacity on jenkins they
should be ok, finger in the air estimate, so we might be even better
than 8.
