Re: [VOTE] Release Apache Cassandra 4.1.7

[Jordan West]

+1. Validated by starting and creating a 3 node cluster using easy-cass-lab.

Jordan

On Fri, Sep 20, 2024 at 7:36 AM Mick Semb Wever  wrote:

>
> Proposing the test build of Cassandra 4.1.7 for release.
>
> sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a
> Git: https://github.com/apache/cassandra/tree/4.1.7-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1347/org/apache/cassandra/cassandra-all/4.1.7/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.7/
>
> ==
> This release introduces safeguards and observability into possible data
> loss scenarios when nodes have a  divergent view of the cluster. This
> happens around edge-cases on unsafe bootstrapping, decommissions, or when a
> node has a corrupted topology. Two configuration options have been added:
> `log_out_of_token_range_requests` and
>  `reject_out_of_token_range_requests`, both enabled by default. The former
> will make nodes log requests they receive that don't belong in their
> current or pending token ranges. The latter will reject those requests,
> which prevents any eventual data loss that can occur but may also incur
> small windows of degraded availability during range movements. See
> CASSANDRA-13704 for further details.
> ==
>
> The vote will be open for 96 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.7-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.1.7-tentative/NEWS.txt
>

Re: CEP-32: Open-Telemetry integration

[Saranya Krishnakumar]

Hi Patrick,

I am interested in working on this CEP collaborating with Yuki. I recently
worked on adding metrics framework in Apache Cassandra Sidecar project.

Best,
Saranya Krishnakumar

On Thu, Sep 19, 2024 at 10:57 AM Patrick McFadin  wrote:

> Here's another stalled CEP. In this case, no discuss thread or Jira.
>
> Yuki (or anyone else) know the status of this CEP?
>
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-32%3A+%28DRAFT%29+OpenTelemetry+integration
>
> Patrick
>

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

Hello everyone,

Cep is being written, and I encountered some problems during the process. I
would like to discuss them with you. If you read the description of this
CASSANDRA-7662 , we
will find that initially the original creator of this jira did not intend
to implement structural copying of indexes, views, and triggers  only the
column and its data type.

However, after investigating some db related syntax and function
implementation, I found that it may be necessary for us to provide some
rich syntax to support the replication of indexes, views, etc.

In order to support selective copy of the basic structure of the table
(columns and types), table options, table-related indexes, views, triggers,
etc. We need some new syntax, it seems that the syntax of pg is relatively
comprehensive, it use the keyword INCLUDING/EXCLUDING to flexibly control
the removal and retention of indexes, table information, etc. see pg create
table like  , the
new created index name is different from the original table's index name ,
seenewly copied index names are different from original

, the name is based on some rule.
Mysql is relatively simple and copies columns and indexes by default. see mysql
create table like
 and the
newly created index name is the same with the original table's index name.

So for Casandra, I hope it can also support the information copy of index
and even view/trigger. And I also hope to be able to flexibly decide which
information is copied like pg.

Besides, I think the copy can happen between different keyspaces. And UDT
needs to be taken into account.

But as we know the index/view/trigger name are all under keyspace level, so
it seems that the newly created index name (or view name/ trigger name)
must be different from the original tables' ,otherwise  names would clash .

So regarding the above problem, one idea I have is that for newly created
types, indexes and views under different keyspaces and the same keyspace,
we first generate random names for them, and then we can add the ability of
modifying the names(for types/indexes/views/triggers) so that users can
manually change the names.


guo Maxwell  于2024年9月20日周五 08:06写道：

> No，I think still need some discuss on grammar detail after I finish the
> first version
>
> Patrick McFadin 于2024年9月20日 周五上午2:24写道：
>
>> Is this CEP ready for a VOTE thread?
>>
>> On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell  wrote:
>>
>>> Thank you for your replies, I will prepare a CEP later.
>>>
>>> Patrick McFadin  于2024年8月20日周二 02:11写道：
>>>
 +1 This is a CEP

 On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad  wrote:

> Given the fairly large surface area for this, i think it should be a
> CEP.
>
> —
> Jon Haddad
> Rustyrazorblade Consulting
> rustyrazorblade.com
>
>
> On Mon, Aug 19, 2024 at 10:44 AM Bernardo Botella <
> conta...@bernardobotella.com> wrote:
>
>> Definitely a nice addition to CQL.
>>
>> Looking for inspiration at how Postgres and Mysql do that may also
>> help with the final design (I like the WITH proposed by Stefan, but I 
>> would
>> definitely take a look at the INCLUDING keyword proposed by Postgres).
>> https://www.postgresql.org/docs/current/sql-createtable.html
>> https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html
>>
>> On top of that, and as part of the interesting questions, I would
>> like to add the permissions to the mix. Both the question about copying
>> them over (with a WITH keyword probably), and the need for read 
>> permissions
>> on the source table as well.
>>
>> Bernardo
>>
>> On Aug 19, 2024, at 10:01 AM, Štefan Miklošovič <
>> smikloso...@apache.org> wrote:
>>
>> BTW this would be cool to do as well:
>>
>> ALTER TABLE ks.to_copy LIKE ks.tb WITH INDICES;
>>
>> This would mean that if we create a copy of a table, later we can
>> decide that we need indices too, so we might "enrich" that table with
>> indices from the old one without necessarily explicitly re-creating them 
>> on
>> that new table.
>>
>> On Mon, Aug 19, 2024 at 6:55 PM Štefan Miklošovič <
>> smikloso...@apache.org> wrote:
>>
>>> I think this is an interesting idea worth exploring. I definitely
>>> agree with Benjamin who raised important questions which needs to be
>>> answered first. Also, what about triggers?
>>>
>>> It might be rather "easy" to come up with something simple but it
>>> should be a comprehensive solution with predictable behavior we all 
>>> agree
>>> on.
>>>
>>> If a keyspace of a new table does not exist we would need to create
>>> that one