Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Štefan Miklošovič]

options are inherently part of that table as well, same as schema. In fact,
_schema_ includes all options. Not just columns and its names. If you
change some option, you effectively have a different schema, schema version
changes by changing an option. So if we do not copy options too, we are
kind of faking it (when we do not specify WITH OPTIONS).

Also, imagine a situation where Accord is merged to trunk. It introduces a
new schema option called "transactional = full" which is not default. (I am
sorry if I did the spelling wrong here). So, when you have a table with
transactional support and you do "create table ks.tb_copy like ks.tb", when
you _do not_ copy all options, this table will _not_ become transactional.

The next thing you go to do is to execute some transactions against this
table but well ... you can not do that, because your table is not
transactional, because you have forgotten to add "WITH OPTIONS". So you
need to go back to that and do "ALTER ks.tb_copy WITH transactional = full"
just to support that.

I think that you see from this pattern that it is way better if we copy all
options by default instead of consciously opt-in into them.

also:

"but I think there are also some users want to do basic column information
copy"

where is this coming from? Do you have this idea somehow empirically
tested? I just do not see why somebody would want to have Cassandra's
defaults instead of what a base table contains.

On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell  wrote:

> The reason for using OPTION keyword is that I want to provide users with
> more choices .
> The default behavior for copying a table is to copy the basic item of
> table （column and their data type，mask，constraint），others thing belongs to
> the table like option，views，trigger
> are optional in my mind.
> You are absolutely right that users may want to copy all stuff but I think
> there are aslo some users want to do basic column information copy，So I
> just give them a choice。As we know that the number of table parameters is
> not small，compression，compaction，gc_seconds，bf_chance，speculative_retry and
> so on.
>
> Besides we can see that pg have also the keyword COMMENT，COMPRESSION which
> have the similar behavior as our OPTION keyword。
>
> So that is why I add this keyword OPTION.
>
>
> Štefan Miklošovič 于2024年10月22日 周二下午11:40写道：
>
>> The problem is that when I do this minimal CQL which shows this feature:
>>
>> CREATE TABLE ks.tb_copy LIKE ks.tb;
>>
>> then you are saying that when I _do not_ specify WITH OPTIONS then I get
>> Cassandra's defaults. Only after I specify WITH OPTIONS, it would truly be
>> a copy.
>>
>> This is not a good design. Because to have an exact copy, I have to make
>> a conscious effort to include OPTIONS as well. That should not be the case.
>> I just want to have a copy, totally the same stuff, when I use the minimal
>> version of that statement. It would be better to opt-out from options like
>>
>> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel me) but we
>> do not support this (yet).
>>
>> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič 
>> wrote:
>>
>>> I just don't see OPTIONS as important. When I want to copy a table, I am
>>> copying a table _with everything_. Options included, by default. Why would
>>> I want to have a copy of a table with options different from the base one?
>>>
>>>
>>> On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
>>> conta...@bernardobotella.com> wrote:
>>>
 Hi Guo,

 +1 for the CONSTRAINTS keyword to be added into the default behavior.

 Bernardo

 On Oct 21, 2024, at 12:01 AM, guo Maxwell  wrote:

 I think the CONSTRAINTS keyword  keyword may be in the same situation
 as datamask.
 Maybe it is better to include  constraints into  the default behavior
 of table copy together with column name, column data type and data mask.

 guo Maxwell  于2024年10月21日周一 14:56写道：

> To yifan :
> I don't mind adding the ALL keyword, and it has been updated into CEP.
>
> As all you can see, our original intention was that the grammar would
> not be too complicated, which is what I described in cep
> 
> .
> We gave up PG-related grammar, including INCLUDING/EXCLUDING and so on
> .
>
> guo Maxwell  于2024年10月21日周一 14:52写道：
>
>> Hi ,
>> To sefan :
>> I may want to explain that if there is no OPTION keyword in the CQL
>> statement, then the newly created table will only have the
>> original table's  column name 、column type and data mask ,I think this is
>> the most basic choice when copying tables to users.
>> Then  we do some  addition, we can add original table's table options
>> like compaction strategy/compress strategy、index and so on.
>>
>> Recently, I have also thought about the situation of CONSTRAINTS
>> keyword. I think 

Re: [DISCUSS] Donating easy-cass-stress to the project

[Mick Semb Wever]

On Wed, 23 Oct 2024 at 05:48, Jordan West  wrote:

> Josh/Mick, where does that leave us? I’d like to start with the smaller
> scope Josh described in his last email. We can tackle in-tree/stress
> separately.
>
> I was going to start working on getting signed ICLAs. Does that still
> sound like the right next step? Or is that also not necessary unless we
> take the approach originally described by Mick?
>


I'm working on getting the SGA from DataStax.   And yes, please collect
ICLAs from those that have contributed past SHA
2d4542c27d3f1c0e24899c01247b9a8ee3c9a238

Re: [DISCUSS] Modeling JIRA fix version for subprojects

[Brandon Williams]

If nobody objects I will be creating the CASS jira projects later today.

Kind Regards,
Brandon

On Tue, Oct 22, 2024 at 10:35 AM Ekaterina Dimitrova
 wrote:
>
> Honestly, counting the letters was also a thing that happened to me but I 
> should admit that even with CASSANDRAANALYTICS we count the As…
>
> My preference is CASSX
>
> Seems shorter and less painful to read to me as a user.
>
> Thanks
>
> On Tue, 22 Oct 2024 at 11:18, Patrick McFadin  wrote:
>>
>> CASS + NAME is my +1
>>
>> TBH rarely with this be typed. Just copied and pasted. It has to be
>> clear that naming is different from the other projects and I think we
>> get it either way.
>>
>> On Tue, Oct 22, 2024 at 8:15 AM Štefan Miklošovič
>>  wrote:
>> >
>> > Something like this?
>> >
>> > CASSANDRA
>> > CASSPYTHON
>> > CASSGO
>> > CASSJAVA
>> > CASSSIDECAR
>> > CASSANALYTICS
>> >
>> > if we expand it would be like
>> >
>> > CASSANDRA
>> > CASSANDRAPYTHON
>> > CASSANDRAGO
>> > CASSANDRAJAVA
>> > CASSANDRASIDECAR
>> > CASSANDRAANALYTICS
>> >
>> > I don't know ... the first form seems fine to me but that triple S in 
>> > CASSSIDECAR is strange. I just find myself counting S's when I type it.
>> >
>> > Up to you guys. I don't mind both.
>> >
>> > On Tue, Oct 22, 2024 at 5:01 PM Brandon Williams  wrote:
>> >>
>> >> I don't think underscore is an option from selfserve anyway.  If we
>> >> have to stick everything together then I think having fewer things is
>> >> better, so we could drop the 'driver' and just name things like
>> >> CASSPYTHON.  WDYT?
>> >>
>> >> Kind Regards,
>> >> Brandon
>> >>
>> >> On Tue, Oct 22, 2024 at 9:33 AM Štefan Miklošovič
>> >>  wrote:
>> >> >
>> >> > So we will have stuff like
>> >> >
>> >> > CASS_DRIVER_PYTHON and all tickets in CHANGES.txt as well as in the 
>> >> > commit messages will be like
>> >> >
>> >> > CASS_DRIVER_PYTHON-1234
>> >> >
>> >> > I checked (1) and there is not a single one which has underscores in 
>> >> > its name, now THAT would be a precedent, wouldn't it ...
>> >> >
>> >> > (1) 
>> >> > https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all
>> >> >
>> >> > On Tue, Oct 22, 2024 at 4:17 PM Martin Sucha  
>> >> > wrote:
>> >> >>
>> >> >> This seems to be relevant documentation: 
>> >> >> https://confluence.atlassian.com/adminjiraserver/changing-the-project-key-format-938847081.html
>> >> >>
>> >> >> Martin
>> >> >>
>> >> >> 
>> >> >> This email, including attached files, may contain confidential 
>> >> >> information and is intended only for the use of the individual and/or 
>> >> >> entity to which it is addressed. If you are not the intended 
>> >> >> recipient, disclosure, copying, use, or distribution of the 
>> >> >> information included in this email and/or in its attachments is 
>> >> >> prohibited.
>> >> >> If you have received it by mistake, please do not read, copy or use 
>> >> >> it, or disclose its contents to others. Please notify the sender that 
>> >> >> you have received this email by mistake by replying to the email, and 
>> >> >> then delete the email and any copies and attachments of it. Thank you.

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Josh McKenzie]

I'm a very strong +1 to having the default functionality be to copy *ALL* 
options.

Intuitively, as a user, if I tell a software system to make a clone of 
something I don't expect it to be shallow or a subset defined by some external 
developer somewhere. I expect it to be a clone.

Adding in some kind of "lean" mode or "column only" is fine if someone can make 
a cogent argument around its inclusion. I don't personally see a use-case for 
it right now but definitely open to being educated.

On Wed, Oct 23, 2024, at 3:03 AM, Štefan Miklošovič wrote:
> options are inherently part of that table as well, same as schema. In fact, 
> _schema_ includes all options. Not just columns and its names. If you change 
> some option, you effectively have a different schema, schema version changes 
> by changing an option. So if we do not copy options too, we are kind of 
> faking it (when we do not specify WITH OPTIONS).
> 
> Also, imagine a situation where Accord is merged to trunk. It introduces a 
> new schema option called "transactional = full" which is not default. (I am 
> sorry if I did the spelling wrong here). So, when you have a table with 
> transactional support and you do "create table ks.tb_copy like ks.tb", when 
> you _do not_ copy all options, this table will _not_ become transactional.
> 
> The next thing you go to do is to execute some transactions against this 
> table but well ... you can not do that, because your table is not 
> transactional, because you have forgotten to add "WITH OPTIONS". So you need 
> to go back to that and do "ALTER ks.tb_copy WITH transactional = full" just 
> to support that.
> 
> I think that you see from this pattern that it is way better if we copy all 
> options by default instead of consciously opt-in into them. 
> 
> also:
> 
> "but I think there are also some users want to do basic column information 
> copy"
> 
> where is this coming from? Do you have this idea somehow empirically tested? 
> I just do not see why somebody would want to have Cassandra's defaults 
> instead of what a base table contains. 
> 
> On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell  wrote:
>> The reason for using OPTION keyword is that I want to provide users with 
>> more choices .
>> The default behavior for copying a table is to copy the basic item of table 
>> （column and their data type，mask，constraint），others thing belongs to the 
>> table like option，views，trigger 
>> are optional in my mind.
>> You are absolutely right that users may want to copy all stuff but I think 
>> there are aslo some users want to do basic column information copy，So I just 
>> give them a choice。As we know that the number of table parameters is not 
>> small，compression，compaction，gc_seconds，bf_chance，speculative_retry and so 
>> on.
>> 
>> Besides we can see that pg have also the keyword COMMENT，COMPRESSION which 
>> have the similar behavior as our OPTION keyword。
>> 
>> So that is why I add this keyword OPTION.
>> 
>> 
>> Štefan Miklošovič 于2024年10月22日 周二下午11:40写道：
>>> The problem is that when I do this minimal CQL which shows this feature:
>>> 
>>> CREATE TABLE ks.tb_copy LIKE ks.tb; 
>>> 
>>> then you are saying that when I _do not_ specify WITH OPTIONS then I get 
>>> Cassandra's defaults. Only after I specify WITH OPTIONS, it would truly be 
>>> a copy. 
>>> 
>>> This is not a good design. Because to have an exact copy, I have to make a 
>>> conscious effort to include OPTIONS as well. That should not be the case. I 
>>> just want to have a copy, totally the same stuff, when I use the minimal 
>>> version of that statement. It would be better to opt-out from options like
>>> 
>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel me) but we do 
>>> not support this (yet).
>>> 
>>> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič  
>>> wrote:
 I just don't see OPTIONS as important. When I want to copy a table, I am 
 copying a table _with everything_. Options included, by default. Why would 
 I want to have a copy of a table with options different from the base one? 
 
 
 On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella 
  wrote:
> Hi Guo,
> 
> +1 for the CONSTRAINTS keyword to be added into the default behavior.
> 
> Bernardo
> 
>> On Oct 21, 2024, at 12:01 AM, guo Maxwell  wrote:
>> 
>> I think the CONSTRAINTS keyword  keyword may be in the same situation as 
>> datamask. 
>> Maybe it is better to include  constraints into  the default behavior of 
>> table copy together with column name, column data type and data mask.
>> 
>> guo Maxwell  于2024年10月21日周一 14:56写道：
>>> To yifan : 
>>> I don't mind adding the ALL keyword, and it has been updated into CEP.
>>> 
>>> As all you can see, our original intention was that the grammar would 
>>> not be too complicated, which is what I described in cep 
>>> 

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Jon Haddad]

Also strongly +1 to copying all the options.


On Wed, Oct 23, 2024 at 5:52 AM Josh McKenzie  wrote:

> I'm a very strong +1 to having the default functionality be to copy *ALL*
> options.
>
> Intuitively, as a user, if I tell a software system to make a clone of
> something I don't expect it to be shallow or a subset defined by some
> external developer somewhere. I expect it to be a clone.
>
> Adding in some kind of "lean" mode or "column only" is fine if someone can
> make a cogent argument around its inclusion. I don't personally see a
> use-case for it right now but definitely open to being educated.
>
> On Wed, Oct 23, 2024, at 3:03 AM, Štefan Miklošovič wrote:
>
> options are inherently part of that table as well, same as schema. In
> fact, _schema_ includes all options. Not just columns and its names. If you
> change some option, you effectively have a different schema, schema version
> changes by changing an option. So if we do not copy options too, we are
> kind of faking it (when we do not specify WITH OPTIONS).
>
> Also, imagine a situation where Accord is merged to trunk. It introduces a
> new schema option called "transactional = full" which is not default. (I am
> sorry if I did the spelling wrong here). So, when you have a table with
> transactional support and you do "create table ks.tb_copy like ks.tb", when
> you _do not_ copy all options, this table will _not_ become transactional.
>
> The next thing you go to do is to execute some transactions against this
> table but well ... you can not do that, because your table is not
> transactional, because you have forgotten to add "WITH OPTIONS". So you
> need to go back to that and do "ALTER ks.tb_copy WITH transactional = full"
> just to support that.
>
> I think that you see from this pattern that it is way better if we copy
> all options by default instead of consciously opt-in into them.
>
> also:
>
> "but I think there are also some users want to do basic column information
> copy"
>
> where is this coming from? Do you have this idea somehow empirically
> tested? I just do not see why somebody would want to have Cassandra's
> defaults instead of what a base table contains.
>
> On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell  wrote:
>
> The reason for using OPTION keyword is that I want to provide users with
> more choices .
> The default behavior for copying a table is to copy the basic item of
> table （column and their data type，mask，constraint），others thing belongs to
> the table like option，views，trigger
> are optional in my mind.
> You are absolutely right that users may want to copy all stuff but I think
> there are aslo some users want to do basic column information copy，So I
> just give them a choice。As we know that the number of table parameters is
> not small，compression，compaction，gc_seconds，bf_chance，speculative_retry and
> so on.
>
> Besides we can see that pg have also the keyword COMMENT，COMPRESSION which
> have the similar behavior as our OPTION keyword。
>
> So that is why I add this keyword OPTION.
>
>
> Štefan Miklošovič 于2024年10月22日 周二下午11:40写道：
>
> The problem is that when I do this minimal CQL which shows this feature:
>
> CREATE TABLE ks.tb_copy LIKE ks.tb;
>
> then you are saying that when I _do not_ specify WITH OPTIONS then I get
> Cassandra's defaults. Only after I specify WITH OPTIONS, it would truly be
> a copy.
>
> This is not a good design. Because to have an exact copy, I have to make a
> conscious effort to include OPTIONS as well. That should not be the case. I
> just want to have a copy, totally the same stuff, when I use the minimal
> version of that statement. It would be better to opt-out from options like
>
> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel me) but we do
> not support this (yet).
>
> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič 
> wrote:
>
> I just don't see OPTIONS as important. When I want to copy a table, I am
> copying a table _with everything_. Options included, by default. Why would
> I want to have a copy of a table with options different from the base one?
>
>
> On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
> conta...@bernardobotella.com> wrote:
>
> Hi Guo,
>
> +1 for the CONSTRAINTS keyword to be added into the default behavior.
>
> Bernardo
>
> On Oct 21, 2024, at 12:01 AM, guo Maxwell  wrote:
>
> I think the CONSTRAINTS keyword  keyword may be in the same situation as
> datamask.
> Maybe it is better to include  constraints into  the default behavior of
> table copy together with column name, column data type and data mask.
>
> guo Maxwell  于2024年10月21日周一 14:56写道：
>
> To yifan :
> I don't mind adding the ALL keyword, and it has been updated into CEP.
>
> As all you can see, our original intention was that the grammar would not
> be too complicated, which is what I described in cep
> 
> .
> We gave up PG-related grammar, including INCLUDING/EXCLUDING and so on

Re: [DISCUSS] Modeling JIRA fix version for subprojects

[Brandon Williams]

https://issues.apache.org/jira/projects/CASSPYTHON/
https://issues.apache.org/jira/projects/CASSJAVA/
https://issues.apache.org/jira/projects/CASSGO/

are now live.  If you know of any issues to move there, please do so.

Kind Regards,
Brandon

On Wed, Oct 23, 2024 at 6:59 AM Brandon Williams  wrote:
>
> If nobody objects I will be creating the CASS jira projects later today.
>
> Kind Regards,
> Brandon
>
> On Tue, Oct 22, 2024 at 10:35 AM Ekaterina Dimitrova
>  wrote:
> >
> > Honestly, counting the letters was also a thing that happened to me but I 
> > should admit that even with CASSANDRAANALYTICS we count the As…
> >
> > My preference is CASSX
> >
> > Seems shorter and less painful to read to me as a user.
> >
> > Thanks
> >
> > On Tue, 22 Oct 2024 at 11:18, Patrick McFadin  wrote:
> >>
> >> CASS + NAME is my +1
> >>
> >> TBH rarely with this be typed. Just copied and pasted. It has to be
> >> clear that naming is different from the other projects and I think we
> >> get it either way.
> >>
> >> On Tue, Oct 22, 2024 at 8:15 AM Štefan Miklošovič
> >>  wrote:
> >> >
> >> > Something like this?
> >> >
> >> > CASSANDRA
> >> > CASSPYTHON
> >> > CASSGO
> >> > CASSJAVA
> >> > CASSSIDECAR
> >> > CASSANALYTICS
> >> >
> >> > if we expand it would be like
> >> >
> >> > CASSANDRA
> >> > CASSANDRAPYTHON
> >> > CASSANDRAGO
> >> > CASSANDRAJAVA
> >> > CASSANDRASIDECAR
> >> > CASSANDRAANALYTICS
> >> >
> >> > I don't know ... the first form seems fine to me but that triple S in 
> >> > CASSSIDECAR is strange. I just find myself counting S's when I type it.
> >> >
> >> > Up to you guys. I don't mind both.
> >> >
> >> > On Tue, Oct 22, 2024 at 5:01 PM Brandon Williams  
> >> > wrote:
> >> >>
> >> >> I don't think underscore is an option from selfserve anyway.  If we
> >> >> have to stick everything together then I think having fewer things is
> >> >> better, so we could drop the 'driver' and just name things like
> >> >> CASSPYTHON.  WDYT?
> >> >>
> >> >> Kind Regards,
> >> >> Brandon
> >> >>
> >> >> On Tue, Oct 22, 2024 at 9:33 AM Štefan Miklošovič
> >> >>  wrote:
> >> >> >
> >> >> > So we will have stuff like
> >> >> >
> >> >> > CASS_DRIVER_PYTHON and all tickets in CHANGES.txt as well as in the 
> >> >> > commit messages will be like
> >> >> >
> >> >> > CASS_DRIVER_PYTHON-1234
> >> >> >
> >> >> > I checked (1) and there is not a single one which has underscores in 
> >> >> > its name, now THAT would be a precedent, wouldn't it ...
> >> >> >
> >> >> > (1) 
> >> >> > https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all
> >> >> >
> >> >> > On Tue, Oct 22, 2024 at 4:17 PM Martin Sucha  
> >> >> > wrote:
> >> >> >>
> >> >> >> This seems to be relevant documentation: 
> >> >> >> https://confluence.atlassian.com/adminjiraserver/changing-the-project-key-format-938847081.html
> >> >> >>
> >> >> >> Martin
> >> >> >>
> >> >> >> 
> >> >> >> This email, including attached files, may contain confidential 
> >> >> >> information and is intended only for the use of the individual 
> >> >> >> and/or entity to which it is addressed. If you are not the intended 
> >> >> >> recipient, disclosure, copying, use, or distribution of the 
> >> >> >> information included in this email and/or in its attachments is 
> >> >> >> prohibited.
> >> >> >> If you have received it by mistake, please do not read, copy or use 
> >> >> >> it, or disclose its contents to others. Please notify the sender 
> >> >> >> that you have received this email by mistake by replying to the 
> >> >> >> email, and then delete the email and any copies and attachments of 
> >> >> >> it. Thank you.

Re: CEP-32: Open-Telemetry integration

[Maxim Muzafarov]

Hello,


I wanted to throw some ideas and a vision in terms of metrics,
trancing and the adoption of new integrations, particularly
OpenTelemetry. I personally feel that the more integrations we have,
the better the adoption of Cassandra as a database will be. With
OpenTelemetry, users could have a better "first experience", so I'm +1
here.

I have two concerns with the way we currently handle such integrations:

1. The first is how do we manage all these integrations, because
according to the CEP we are adding new dependencies and interfaces [1]
to the project and adding new configuration values, this is not bad in
itself. However, it also means that as the number of integrations
increases, so does the maintenance of the project and config (the
vision - is to have minimal extra deps in the core and the smallest
config).

2. Exporting metrics/logs should not affect the node itself (adjusting
the JVM params [2] of the node to make the integration work tells us
that we are doing something wrong) and the JVM process that does the
main work with the data by handling user requests. The priority of
serving metrics/logs is lower than a user request. The current
approach of adding new metric exporters and/or instrumenting JVM
agents could affect the stability and performance of the node, the
bugs could prevent the node from serving user requests as well (e.g.
calculating instead of exporting raw histograms [3] causing gcs and
impacts the node).



With all that, the alternate solution and the vision I'm trying to
highlight here is that we should just rely on the native protocol and
"incorporate" these things into the native protocol itself and CQL as
its part.
That way, Cassandra Sidecar and other sub-projects interested in the
internal state of the node can rely only on the protocol specification
and the query syntax.

Specifically, querying the node's internal state (basically metrics
and logs) is being done using two paradigms: "poll" and "push".

1. The "poll" is the simplest part, we already have all we need - lots
of virtual tables. A new virtual keyspace "system_metrics" [4]
contains all the internal metrics in the Prometheus format that
Cassandra exposes in JMX, and can be queried by any other system (e.g.
the Cassandra Sidecar that has established a local connection via Unix
Domain Socket to query the metrics) to expose them via the REST API or
other interfaces they need. The efficiency of exposing these metrics
is the best we can offer in terms of performance (I hope).

2. The "push" is currently and unfortunately is not implemented - but
normally is used and designed to export logs and internal events. The
vision is - to register a continuous query to listen for the log
updates on the node, which is also a part of the Sidecar. Such a
feature would be useful in itself, regardless of the fact that in our
case we are going to use it to listen to internal events and log
updates. From my point of view, other database vendors offer something
similar that Cassandra lacks:

https://cloud.google.com/bigquery/docs/continuous-queries-introduction
https://docs.influxdata.com/influxdb/v1/query_language/continuous_queries/

The syntax could be:

CREATE CONTINUOUS QUERY cq_log_updates ON system_queries
BEGIN
  SELECT timestamp, text FROM system_logs
END

These two paradigms can be collected under the umbrella of the
Cassandra Sidecar to support the OpenTelemetry without having extra
config and extra dependency and leaving the Cassandra core with no
additional dependencies and free to focus on the native protocol and
CQL.



By far, it was all about metrics and logs. I also took a look at the
opentelemetry-demo project to see what a trace might look like. The
example [5] shows a good picture of a tracing request up to the point
where the request reaches the core, and from that point on the trace
picture becomes foggy, showing almost nothing about Cassndra
internals. I think this part should be improved by adding traceable
types for each of the internal components we want to trace (messaging
between nodes, the waiting time in a pool, the time to parse a request
etc.). For instance, here is an example [6] of what the granularity
could look like.

With that, and since we would somehow have specific trace types for
Cassandra to view on internal components, I think the point where we
can bind Cassandra traces to the OpenTelemetry trace context is the
Sidecar (the best candidate from my point of view). Theoretically, we
could use the opentelemetry-java-instrumentation [7] to get an
overview of the internals, but without custom Cassandra trancing types
it won't give us good granularity and a clear picture of the node
internals.


Please don't take this as a criticism or -1 on my part, just wanted to
share an alternative way it could have been seen. The amount of extra
dependencies scares me so much :-)


[1] 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-32%3A+%28DRAFT%29+OpenTelemetry+integration#CEP32:(DRAFT)Ope

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

OK，thank you for your suggestions ，I will revise the CEP and copy table
OPTIONS by default.

Jon Haddad 于2024年10月23日 周三下午9:18写道：

> Also strongly +1 to copying all the options.
>
>
> On Wed, Oct 23, 2024 at 5:52 AM Josh McKenzie 
> wrote:
>
>> I'm a very strong +1 to having the default functionality be to copy *ALL*
>> options.
>>
>> Intuitively, as a user, if I tell a software system to make a clone of
>> something I don't expect it to be shallow or a subset defined by some
>> external developer somewhere. I expect it to be a clone.
>>
>> Adding in some kind of "lean" mode or "column only" is fine if someone
>> can make a cogent argument around its inclusion. I don't personally see a
>> use-case for it right now but definitely open to being educated.
>>
>> On Wed, Oct 23, 2024, at 3:03 AM, Štefan Miklošovič wrote:
>>
>> options are inherently part of that table as well, same as schema. In
>> fact, _schema_ includes all options. Not just columns and its names. If you
>> change some option, you effectively have a different schema, schema version
>> changes by changing an option. So if we do not copy options too, we are
>> kind of faking it (when we do not specify WITH OPTIONS).
>>
>> Also, imagine a situation where Accord is merged to trunk. It introduces
>> a new schema option called "transactional = full" which is not default. (I
>> am sorry if I did the spelling wrong here). So, when you have a table with
>> transactional support and you do "create table ks.tb_copy like ks.tb", when
>> you _do not_ copy all options, this table will _not_ become transactional.
>>
>> The next thing you go to do is to execute some transactions against this
>> table but well ... you can not do that, because your table is not
>> transactional, because you have forgotten to add "WITH OPTIONS". So you
>> need to go back to that and do "ALTER ks.tb_copy WITH transactional = full"
>> just to support that.
>>
>> I think that you see from this pattern that it is way better if we copy
>> all options by default instead of consciously opt-in into them.
>>
>> also:
>>
>> "but I think there are also some users want to do basic column
>> information copy"
>>
>> where is this coming from? Do you have this idea somehow empirically
>> tested? I just do not see why somebody would want to have Cassandra's
>> defaults instead of what a base table contains.
>>
>> On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell  wrote:
>>
>> The reason for using OPTION keyword is that I want to provide users with
>> more choices .
>> The default behavior for copying a table is to copy the basic item of
>> table （column and their data type，mask，constraint），others thing belongs to
>> the table like option，views，trigger
>> are optional in my mind.
>> You are absolutely right that users may want to copy all stuff but I
>> think there are aslo some users want to do basic column information copy，So
>> I just give them a choice。As we know that the number of table parameters is
>> not small，compression，compaction，gc_seconds，bf_chance，speculative_retry and
>> so on.
>>
>> Besides we can see that pg have also the keyword COMMENT，COMPRESSION
>> which have the similar behavior as our OPTION keyword。
>>
>> So that is why I add this keyword OPTION.
>>
>>
>> Štefan Miklošovič 于2024年10月22日 周二下午11:40写道：
>>
>> The problem is that when I do this minimal CQL which shows this feature:
>>
>> CREATE TABLE ks.tb_copy LIKE ks.tb;
>>
>> then you are saying that when I _do not_ specify WITH OPTIONS then I get
>> Cassandra's defaults. Only after I specify WITH OPTIONS, it would truly be
>> a copy.
>>
>> This is not a good design. Because to have an exact copy, I have to make
>> a conscious effort to include OPTIONS as well. That should not be the case.
>> I just want to have a copy, totally the same stuff, when I use the minimal
>> version of that statement. It would be better to opt-out from options like
>>
>> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel me) but we
>> do not support this (yet).
>>
>> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič 
>> wrote:
>>
>> I just don't see OPTIONS as important. When I want to copy a table, I am
>> copying a table _with everything_. Options included, by default. Why would
>> I want to have a copy of a table with options different from the base one?
>>
>>
>> On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
>> conta...@bernardobotella.com> wrote:
>>
>> Hi Guo,
>>
>> +1 for the CONSTRAINTS keyword to be added into the default behavior.
>>
>> Bernardo
>>
>> On Oct 21, 2024, at 12:01 AM, guo Maxwell  wrote:
>>
>> I think the CONSTRAINTS keyword  keyword may be in the same situation as
>> datamask.
>> Maybe it is better to include  constraints into  the default behavior of
>> table copy together with column name, column data type and data mask.
>>
>> guo Maxwell  于2024年10月21日周一 14:56写道：
>>
>> To yifan :
>> I don't mind adding the ALL keyword, and it has been updated into CEP.
>>
>> As all you can see, our original intention was that the g

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Dave Herrington]

Strong +1 to copy all options by default. This is intuitive to me.  Then I
would like to explicitly override any options of my choosing.

-Dave

On Wed, Oct 23, 2024 at 9:57 PM guo Maxwell  wrote:

> OK，thank you for your suggestions ，I will revise the CEP and copy table
> OPTIONS by default.
>
> Jon Haddad 于2024年10月23日 周三下午9:18写道：
>
>> Also strongly +1 to copying all the options.
>>
>>
>> On Wed, Oct 23, 2024 at 5:52 AM Josh McKenzie 
>> wrote:
>>
>>> I'm a very strong +1 to having the default functionality be to copy
>>> *ALL* options.
>>>
>>> Intuitively, as a user, if I tell a software system to make a clone of
>>> something I don't expect it to be shallow or a subset defined by some
>>> external developer somewhere. I expect it to be a clone.
>>>
>>> Adding in some kind of "lean" mode or "column only" is fine if someone
>>> can make a cogent argument around its inclusion. I don't personally see a
>>> use-case for it right now but definitely open to being educated.
>>>
>>> On Wed, Oct 23, 2024, at 3:03 AM, Štefan Miklošovič wrote:
>>>
>>> options are inherently part of that table as well, same as schema. In
>>> fact, _schema_ includes all options. Not just columns and its names. If you
>>> change some option, you effectively have a different schema, schema version
>>> changes by changing an option. So if we do not copy options too, we are
>>> kind of faking it (when we do not specify WITH OPTIONS).
>>>
>>> Also, imagine a situation where Accord is merged to trunk. It introduces
>>> a new schema option called "transactional = full" which is not default. (I
>>> am sorry if I did the spelling wrong here). So, when you have a table with
>>> transactional support and you do "create table ks.tb_copy like ks.tb", when
>>> you _do not_ copy all options, this table will _not_ become transactional.
>>>
>>> The next thing you go to do is to execute some transactions against this
>>> table but well ... you can not do that, because your table is not
>>> transactional, because you have forgotten to add "WITH OPTIONS". So you
>>> need to go back to that and do "ALTER ks.tb_copy WITH transactional = full"
>>> just to support that.
>>>
>>> I think that you see from this pattern that it is way better if we copy
>>> all options by default instead of consciously opt-in into them.
>>>
>>> also:
>>>
>>> "but I think there are also some users want to do basic column
>>> information copy"
>>>
>>> where is this coming from? Do you have this idea somehow empirically
>>> tested? I just do not see why somebody would want to have Cassandra's
>>> defaults instead of what a base table contains.
>>>
>>> On Wed, Oct 23, 2024 at 8:28 AM guo Maxwell 
>>> wrote:
>>>
>>> The reason for using OPTION keyword is that I want to provide users with
>>> more choices .
>>> The default behavior for copying a table is to copy the basic item of
>>> table （column and their data type，mask，constraint），others thing belongs to
>>> the table like option，views，trigger
>>> are optional in my mind.
>>> You are absolutely right that users may want to copy all stuff but I
>>> think there are aslo some users want to do basic column information copy，So
>>> I just give them a choice。As we know that the number of table parameters is
>>> not small，compression，compaction，gc_seconds，bf_chance，speculative_retry and
>>> so on.
>>>
>>> Besides we can see that pg have also the keyword COMMENT，COMPRESSION
>>> which have the similar behavior as our OPTION keyword。
>>>
>>> So that is why I add this keyword OPTION.
>>>
>>>
>>> Štefan Miklošovič 于2024年10月22日 周二下午11:40写道：
>>>
>>> The problem is that when I do this minimal CQL which shows this feature:
>>>
>>> CREATE TABLE ks.tb_copy LIKE ks.tb;
>>>
>>> then you are saying that when I _do not_ specify WITH OPTIONS then I get
>>> Cassandra's defaults. Only after I specify WITH OPTIONS, it would truly be
>>> a copy.
>>>
>>> This is not a good design. Because to have an exact copy, I have to make
>>> a conscious effort to include OPTIONS as well. That should not be the case.
>>> I just want to have a copy, totally the same stuff, when I use the minimal
>>> version of that statement. It would be better to opt-out from options like
>>>
>>> CREATE TABLE ks.tb_copy LIKE ks.tb WITHOUT OPTIONS (you feel me) but we
>>> do not support this (yet).
>>>
>>> On Tue, Oct 22, 2024 at 5:28 PM Štefan Miklošovič <
>>> smikloso...@apache.org> wrote:
>>>
>>> I just don't see OPTIONS as important. When I want to copy a table, I am
>>> copying a table _with everything_. Options included, by default. Why would
>>> I want to have a copy of a table with options different from the base one?
>>>
>>>
>>> On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
>>> conta...@bernardobotella.com> wrote:
>>>
>>> Hi Guo,
>>>
>>> +1 for the CONSTRAINTS keyword to be added into the default behavior.
>>>
>>> Bernardo
>>>
>>> On Oct 21, 2024, at 12:01 AM, guo Maxwell  wrote:
>>>
>>> I think the CONSTRAINTS keyword  keyword may be in the same situation as
>>> datamask.
>>>