Re: Google Season of Docs

[Ekaterina Dimitrova]

Thank you for your efforts Lorina!

On Tue, 4 Apr 2023 at 16:26, Deepak Vohra via dev 
wrote:

>   I noticed that fewer projects were selected this year and no Apache
> project was selected.
>
> On Monday, April 3, 2023 at 06:07:53 p.m. EDT, Nate McCall <
> zznat...@gmail.com> wrote:
>
>
> Thank you for your effort regardless, Lorina. Very much appreciated!
>
> On Tue, Apr 4, 2023 at 6:39 AM lorinapoland 
> wrote:
>
> Sadly, I am informing the community that our grant application to GSoD was
> unsuccessful.
>
> If you would like to see the list of winning projects, check out
> https://developers.google.com/season-of-docs/docs/participants.
>
> Lorina
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>

Re: Google Season of Docs

[Deepak Vohra via dev]

   I noticed that fewer projects were selected this year and no Apache project 
was selected. 
On Monday, April 3, 2023 at 06:07:53 p.m. EDT, Nate McCall 
 wrote:  
 
 Thank you for your effort regardless, Lorina. Very much appreciated!

On Tue, Apr 4, 2023 at 6:39 AM lorinapoland  wrote:

Sadly, I am informing the community that our grant application to GSoD was 
unsuccessful. 
If you would like to see the list of winning projects, check out 
https://developers.google.com/season-of-docs/docs/participants.
Lorina


Sent from my Verizon, Samsung Galaxy smartphone

  

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Henrik Ingo]

I find the Postgres terminology overly complex. Where most SQL databases
will have several *databases*, each containing several *tables*, in
Postgres we have namespaces, databases, schemas and tables...

Oracle seems to also use the words database, schema and tables. I don't
know if it has namespaces.

Ah, ok, so SQL Server actually is like Oracle too!


So in MySQL, referring unambiguously (aka full path) to a table would be:

SELECT * FROM mydb.mytable;

Whereas in Postgresql and Oracle and SQL Server you'd have to:

SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to
do with the namespace! */


https://www.postgresql.org/docs/current/catalog-pg-namespace.html
https://www.postgresql.org/docs/current/ddl-schemas.html
https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool

The Microsoft docs perhaps best explain the role of each: The Database
contains the configuration of physical things like where on disk is the
database stored. The Schema on the other hand contains "logical" objects
like tables, views andprocedures.

MongoDB has databases and collections. As an easter egg / inside joke, it
also supports the command `SHOW TABLES` as a synonym for collections.

A TABLESPACE btw is something else completely:
https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053



Personally I would be in favor of introducing `DATABASE` as a synonym for
KEYSPACE. The latter could remain the "official" usage.

henrik


On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski <
lewandowski.ja...@gmail.com> wrote:

> While for someone who already knows Cassandra keyspace is something
> natural, for newcomers it is yet another concept to understand.
>
> If namespace is used in PostgreSQL, it sounds even better to me.
>
> Thanks,
> - - -- --- -  -
> Jacek Lewandowski
>
>
> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh 
> napisał(a):
>
>> My 2 cents:
>>
>> Keeping it keyspace works for me, namespace could be cool also since we
>> decide where that namespace exists in relation to Datacenters, etc.  In our
>> case, a Keyspace is more similar to a namespace than it is to a database
>> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
>> that keyspace/namespace.
>>
>> Alternatively interesting to observe and throw some fuel into the
>> discussion , looking at the Postgres (only because there are many
>> distributed databases that are now PG compliant) :
>> From the interwebs:
>> *In PostgreSQL, a schema is a namespace that contains named database
>> objects such as tables, views, indexes, data types, functions, stored
>> procedures and operators. A database can contain one or multiple schemas
>> and each schema belongs to only one database.*
>> I used to gripe about this but as a platform gets more complex it is
>> useful to organize PG DBs into schemas. In C* world, I found myself doing
>> similar things by having a prefix : e.g. appprefix_system1
>> appprefix_system2 ...
>>
>>
>> Rahul Singh
>>
>> Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
>> rahul.si...@anant.us li: http://linkedin.com/in/xingh
>> 
>> ca: http://calendly.com/xingh
>> 
>>
>> *We create, support, and manage real-time global data & analytics
>> platforms for the modern enterprise.*
>>
>> *Anant | https://anant.us
>> *
>>
>> 3 Washington Circle, Suite 301
>>
>> Washington, D.C. 20037
>>
>> *http://Cassandra.Link
>> *
>>  :
>> The best resources for Apache Cassandra
>>
>>
>> On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:
>>
>>> KEYSPACE at least makes sense in the context that it is the unit that
>>> defines how those partitions keys are going to be treated/replicated
>>>
>>> DATABASE may be ambiguous, but it's ambiguity shared across the
>>> industry.
>>>
>>> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible
>>> because it'll be unique to us in the world, and therefore unintuitive for
>>> new users.
>>>
>>>
>>>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Jacek Lewandowski]

While for someone who already knows Cassandra keyspace is something
natural, for newcomers it is yet another concept to understand.

If namespace is used in PostgreSQL, it sounds even better to me.

Thanks,
- - -- --- -  -
Jacek Lewandowski


wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh 
napisał(a):

> My 2 cents:
>
> Keeping it keyspace works for me, namespace could be cool also since we
> decide where that namespace exists in relation to Datacenters, etc.  In our
> case, a Keyspace is more similar to a namespace than it is to a database
> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
> that keyspace/namespace.
>
> Alternatively interesting to observe and throw some fuel into the
> discussion , looking at the Postgres (only because there are many
> distributed databases that are now PG compliant) :
> From the interwebs:
> *In PostgreSQL, a schema is a namespace that contains named database
> objects such as tables, views, indexes, data types, functions, stored
> procedures and operators. A database can contain one or multiple schemas
> and each schema belongs to only one database.*
> I used to gripe about this but as a platform gets more complex it is
> useful to organize PG DBs into schemas. In C* world, I found myself doing
> similar things by having a prefix : e.g. appprefix_system1
> appprefix_system2 ...
>
>
> Rahul Singh
>
> Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
> rahul.si...@anant.us li: http://linkedin.com/in/xingh ca:
> http://calendly.com/xingh
>
> *We create, support, and manage real-time global data & analytics
> platforms for the modern enterprise.*
>
> *Anant | https://anant.us *
>
> 3 Washington Circle, Suite 301
>
> Washington, D.C. 20037
>
> *http://Cassandra.Link * : The best resources for
> Apache Cassandra
>
>
> On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:
>
>> KEYSPACE at least makes sense in the context that it is the unit that
>> defines how those partitions keys are going to be treated/replicated
>>
>> DATABASE may be ambiguous, but it's ambiguity shared across the industry.
>>
>> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
>> it'll be unique to us in the world, and therefore unintuitive for new users.
>>
>>
>>
>> On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie 
>> wrote:
>>
>>> I think there's competing dynamics here.
>>>
>>> 1) KEYSPACE isn't that great of a name; it's not a space in which keys
>>> are necessarily unique, and you can't address things just by key w/out
>>> their respective tables
>>> 2) DATABASE isn't that great of a name either due to the aforementioned
>>> ambiguity.
>>>
>>> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically*
>>> better satisfy point 1 and 2 above but subjectively I kind of recoil at
>>> both equally. So there's that.
>>>
>>> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>>>
>>> I agree with Bowen - I find Keyspace easier to communicate with. There
>>> are plenty of situations where the use of "database" is ambiguous (like
>>> "Could you help me connect to database x?"), but Keyspace refers to a
>>> single thing. I think more software is moving towards calling these things
>>> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
>>> this way elsewhere, I still find it leads to clearer communication.
>>>
>>> --
>>> Abe
>>>
>>>
>>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
>>> wrote:
>>>
>>> I think supporting DATABASE is a great idea.
>>>
>>> It's better aligned with SQL databases, and can save new users one of
>>> the first troubles they find.
>>>
>>> Probably anyone starting to use Cassandra for the first time is going to
>>> face the what is a keyspace? question in the first minutes. Saving that to
>>> users with a more common name would be a victory for usability IMO.
>>>
>>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>>>
>>> Hi,
>>>
>>> I'd like to propose that we add DATABASE to the CQL grammar as an
>>> alternative to KEYSPACE.
>>>
>>> Background: While TABLE was introduced as an alternative for
>>> COLUMNFAMILY in the grammar we have kept KEYSPACE for the container name
>>> for a group of tables. Nearly all traditional SQL databases use DATABASE as
>>> the container name for a group of tables so it would make sense for
>>> Cassandra to adopt this naming as well.
>>>
>>> KEYSPACE would be kept in the grammar but we would update some logging
>>> and documentation to encourage use of the new name.
>>>
>>> Mike Adamson
>>>
>>> --
>>> [image: DataStax Logo Square] 
>>> *Mike Adamson*
>>> Engineering
>>> +1 650 389 6000 <16503896000> | datastax.com 
>>> Find DataStax Online:
>>> [image: LinkedIn Logo]
>>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Rahul Xavier Singh]

My 2 cents:

Keeping it keyspace works for me, namespace could be cool also since we
decide where that namespace exists in relation to Datacenters, etc.  In our
case, a Keyspace is more similar to a namespace than it is to a database
since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
that keyspace/namespace.

Alternatively interesting to observe and throw some fuel into the
discussion , looking at the Postgres (only because there are many
distributed databases that are now PG compliant) :
>From the interwebs:
*In PostgreSQL, a schema is a namespace that contains named database
objects such as tables, views, indexes, data types, functions, stored
procedures and operators. A database can contain one or multiple schemas
and each schema belongs to only one database.*
I used to gripe about this but as a platform gets more complex it is useful
to organize PG DBs into schemas. In C* world, I found myself doing similar
things by having a prefix : e.g. appprefix_system1 appprefix_system2 ...


Rahul Singh

Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
rahul.si...@anant.us li: http://linkedin.com/in/xingh ca:
http://calendly.com/xingh

*We create, support, and manage real-time global data & analytics platforms
for the modern enterprise.*

*Anant | https://anant.us *

3 Washington Circle, Suite 301

Washington, D.C. 20037

*http://Cassandra.Link * : The best resources for
Apache Cassandra


On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:

> KEYSPACE at least makes sense in the context that it is the unit that
> defines how those partitions keys are going to be treated/replicated
>
> DATABASE may be ambiguous, but it's ambiguity shared across the industry.
>
> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
> it'll be unique to us in the world, and therefore unintuitive for new users.
>
>
>
> On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie  wrote:
>
>> I think there's competing dynamics here.
>>
>> 1) KEYSPACE isn't that great of a name; it's not a space in which keys
>> are necessarily unique, and you can't address things just by key w/out
>> their respective tables
>> 2) DATABASE isn't that great of a name either due to the aforementioned
>> ambiguity.
>>
>> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
>> satisfy point 1 and 2 above but subjectively I kind of recoil at both
>> equally. So there's that.
>>
>> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>>
>> I agree with Bowen - I find Keyspace easier to communicate with. There
>> are plenty of situations where the use of "database" is ambiguous (like
>> "Could you help me connect to database x?"), but Keyspace refers to a
>> single thing. I think more software is moving towards calling these things
>> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
>> this way elsewhere, I still find it leads to clearer communication.
>>
>> --
>> Abe
>>
>>
>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
>> wrote:
>>
>> I think supporting DATABASE is a great idea.
>>
>> It's better aligned with SQL databases, and can save new users one of the
>> first troubles they find.
>>
>> Probably anyone starting to use Cassandra for the first time is going to
>> face the what is a keyspace? question in the first minutes. Saving that to
>> users with a more common name would be a victory for usability IMO.
>>
>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>>
>> Hi,
>>
>> I'd like to propose that we add DATABASE to the CQL grammar as an
>> alternative to KEYSPACE.
>>
>> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
>> in the grammar we have kept KEYSPACE for the container name for a group of
>> tables. Nearly all traditional SQL databases use DATABASE as the container
>> name for a group of tables so it would make sense for Cassandra to adopt
>> this naming as well.
>>
>> KEYSPACE would be kept in the grammar but we would update some logging
>> and documentation to encourage use of the new name.
>>
>> Mike Adamson
>>
>> --
>> [image: DataStax Logo Square] 
>> *Mike Adamson*
>> Engineering
>> +1 650 389 6000 <16503896000> | datastax.com 
>> Find DataStax Online:
>> [image: LinkedIn Logo]
>> 
>>[image: Facebook Logo]
>> 
>>[image: Twitter Logo]    [image: RSS
>> Feed] 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Jeff Jirsa]

KEYSPACE at least makes sense in the context that it is the unit that
defines how those partitions keys are going to be treated/replicated

DATABASE may be ambiguous, but it's ambiguity shared across the industry.

Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
it'll be unique to us in the world, and therefore unintuitive for new users.



On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie  wrote:

> I think there's competing dynamics here.
>
> 1) KEYSPACE isn't that great of a name; it's not a space in which keys are
> necessarily unique, and you can't address things just by key w/out their
> respective tables
> 2) DATABASE isn't that great of a name either due to the aforementioned
> ambiguity.
>
> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
> satisfy point 1 and 2 above but subjectively I kind of recoil at both
> equally. So there's that.
>
> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>
> I agree with Bowen - I find Keyspace easier to communicate with. There are
> plenty of situations where the use of "database" is ambiguous (like "Could
> you help me connect to database x?"), but Keyspace refers to a single
> thing. I think more software is moving towards calling these things
> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
> this way elsewhere, I still find it leads to clearer communication.
>
> --
> Abe
>
>
> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
> wrote:
>
> I think supporting DATABASE is a great idea.
>
> It's better aligned with SQL databases, and can save new users one of the
> first troubles they find.
>
> Probably anyone starting to use Cassandra for the first time is going to
> face the what is a keyspace? question in the first minutes. Saving that to
> users with a more common name would be a victory for usability IMO.
>
> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>
> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
>
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
>
> Mike Adamson
>
> --
> [image: DataStax Logo Square] 
> *Mike Adamson*
> Engineering
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online:
> [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Josh McKenzie]

I think there's competing dynamics here.

1) KEYSPACE isn't that great of a name; it's not a space in which keys are 
necessarily unique, and you can't address things just by key w/out their 
respective tables
2) DATABASE isn't that great of a name either due to the aforementioned 
ambiguity.

Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better 
satisfy point 1 and 2 above but subjectively I kind of recoil at both equally. 
So there's that.

On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
> I agree with Bowen - I find Keyspace easier to communicate with. There are 
> plenty of situations where the use of "database" is ambiguous (like "Could 
> you help me connect to database x?"), but Keyspace refers to a single thing. 
> I think more software is moving towards calling these things "namespaces" 
> (like Kubernetes), and while "Keyspaces" is not a term used in this way 
> elsewhere, I still find it leads to clearer communication.
> 
> --
> Abe
> 
> 
>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña  wrote:
>> 
>> I think supporting DATABASE is a great idea. 
>> 
>> It's better aligned with SQL databases, and can save new users one of the 
>> first troubles they find. 
>> 
>> Probably anyone starting to use Cassandra for the first time is going to 
>> face the what is a keyspace? question in the first minutes. Saving that to 
>> users with a more common name would be a victory for usability IMO.
>> 
>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>>> Hi,
>>> 
>>> I'd like to propose that we add DATABASE to the CQL grammar as an 
>>> alternative to KEYSPACE. 
>>> 
>>> Background: While TABLE was introduced as an alternative for COLUMNFAMILY 
>>> in the grammar we have kept KEYSPACE for the container name for a group of 
>>> tables. Nearly all traditional SQL databases use DATABASE as the container 
>>> name for a group of tables so it would make sense for Cassandra to adopt 
>>> this naming as well.
>>> 
>>> KEYSPACE would be kept in the grammar but we would update some logging and 
>>> documentation to encourage use of the new name. 
>>> 
>>> Mike Adamson
>>> 
>>> --
>>> DataStax Logo Square 
>>> *Mike Adamson*
>>> Engineering
>>> +1 650 389 6000  | datastax.com 
>>> Find DataStax Online:
>>> LinkedIn Logo 
>>> 
>>>Facebook Logo 
>>> 
>>>Twitter Logo    RSS Feed 
>>>    Github Logo 
>>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Abe Ratnofsky]

I agree with Bowen - I find Keyspace easier to communicate with. There are 
plenty of situations where the use of "database" is ambiguous (like "Could you 
help me connect to database x?"), but Keyspace refers to a single thing. I 
think more software is moving towards calling these things "namespaces" (like 
Kubernetes), and while "Keyspaces" is not a term used in this way elsewhere, I 
still find it leads to clearer communication.

--
Abe


> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña  wrote:
> 
> I think supporting DATABASE is a great idea. 
> 
> It's better aligned with SQL databases, and can save new users one of the 
> first troubles they find. 
> 
> Probably anyone starting to use Cassandra for the first time is going to face 
> the what is a keyspace? question in the first minutes. Saving that to users 
> with a more common name would be a victory for usability IMO.
> 
> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  > wrote:
>> Hi,
>> 
>> I'd like to propose that we add DATABASE to the CQL grammar as an 
>> alternative to KEYSPACE. 
>> 
>> Background: While TABLE was introduced as an alternative for COLUMNFAMILY in 
>> the grammar we have kept KEYSPACE for the container name for a group of 
>> tables. Nearly all traditional SQL databases use DATABASE as the container 
>> name for a group of tables so it would make sense for Cassandra to adopt 
>> this naming as well.
>> 
>> KEYSPACE would be kept in the grammar but we would update some logging and 
>> documentation to encourage use of the new name. 
>> 
>> Mike Adamson
>> 
>> -- 
>>   Mike Adamson
>> Engineering
>> 
>> +1 650 389 6000  | datastax.com 
>> Find DataStax Online: 
>> 
>> 
>> 
>> 
>> 
>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Andrés de la Peña]

I think supporting DATABASE is a great idea.

It's better aligned with SQL databases, and can save new users one of the
first troubles they find.

Probably anyone starting to use Cassandra for the first time is going to
face the what is a keyspace? question in the first minutes. Saving that to
users with a more common name would be a victory for usability IMO.

On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:

> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
>
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
>
> Mike Adamson
>
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Bowen Song via dev]

I personally prefer to use the name "keyspace", because it avoids the 
confusion between the "database software/server" and the "collection of 
tables in a database". "An SQL database" can mean different things in 
different contexts, but "a Cassandra keyspace" always mean the same thing.


On 04/04/2023 16:48, Mike Adamson wrote:

Hi,

I'd like to propose that we add DATABASE to the CQL grammar as an 
alternative to KEYSPACE.


Background: While TABLE was introduced as an alternative for 
COLUMNFAMILY in the grammar we have kept KEYSPACE for the container 
name for a group of tables. Nearly all traditional SQL databases use 
DATABASE as the container name for a group of tables so it would make 
sense for Cassandra to adopt this naming as well.


KEYSPACE would be kept in the grammar but we would update some logging 
and documentation to encourage use of the new name.


Mike Adamson

--
DataStax Logo Square   *Mike Adamson*
Engineering

+1 650 389 6000 |datastax.com 



Find DataStax Online: 	LinkedIn Logo 
 
Facebook Logo 
 
Twitter Logo  RSS Feed 
 Github Logo 

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Ekaterina Dimitrova]

+1

On Tue, 4 Apr 2023 at 11:44, Benjamin Lerer  wrote:

> +1
>
> Le mar. 4 avr. 2023 à 17:17, Andrés de la Peña  a
> écrit :
>
>> +1
>>
>> On Tue, 4 Apr 2023 at 15:09, Jeremy Hanna 
>> wrote:
>>
>>> +1 nb, will be great to have this in the codebase - it will make nearly
>>> every table's compaction work more efficiently.  The only possible
>>> exception is tables that are well suited for TWCS.
>>>
>>> On Apr 4, 2023, at 8:00 AM, Berenguer Blasi 
>>> wrote:
>>>
>>> +1
>>> On 4/4/23 14:36, J. D. Jordan wrote:
>>>
>>> +1
>>>
>>> On Apr 4, 2023, at 7:29 AM, Brandon Williams 
>>>  wrote:
>>>
>>> 
>>> +1
>>>
>>> On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:
>>>
 Hi everyone,

 I would like to put CEP-26 to a vote.

 Proposal:

 https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy

 JIRA and draft implementation:
 https://issues.apache.org/jira/browse/CASSANDRA-18397

 Up-to-date documentation:

 https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md

 Discussion:
 https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b

 The vote will be open for 72 hours.
 A vote passes if there are at least three binding +1s and no binding
 vetoes.

 Thanks,
 Branimir

>>>
>>>

[DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Mike Adamson]

Hi,

I'd like to propose that we add DATABASE to the CQL grammar as an
alternative to KEYSPACE.

Background: While TABLE was introduced as an alternative for COLUMNFAMILY
in the grammar we have kept KEYSPACE for the container name for a group of
tables. Nearly all traditional SQL databases use DATABASE as the container
name for a group of tables so it would make sense for Cassandra to adopt
this naming as well.

KEYSPACE would be kept in the grammar but we would update some logging and
documentation to encourage use of the new name.

Mike Adamson

-- 
[image: DataStax Logo Square]  *Mike Adamson*
Engineering

+1 650 389 6000 <16503896000> | datastax.com 
Find DataStax Online: [image: LinkedIn Logo]

   [image: Facebook Logo]

   [image: Twitter Logo]    [image: RSS Feed]
   [image: Github Logo]

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Benjamin Lerer]

+1

Le mar. 4 avr. 2023 à 17:17, Andrés de la Peña  a
écrit :

> +1
>
> On Tue, 4 Apr 2023 at 15:09, Jeremy Hanna 
> wrote:
>
>> +1 nb, will be great to have this in the codebase - it will make nearly
>> every table's compaction work more efficiently.  The only possible
>> exception is tables that are well suited for TWCS.
>>
>> On Apr 4, 2023, at 8:00 AM, Berenguer Blasi 
>> wrote:
>>
>> +1
>> On 4/4/23 14:36, J. D. Jordan wrote:
>>
>> +1
>>
>> On Apr 4, 2023, at 7:29 AM, Brandon Williams 
>>  wrote:
>>
>> 
>> +1
>>
>> On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:
>>
>>> Hi everyone,
>>>
>>> I would like to put CEP-26 to a vote.
>>>
>>> Proposal:
>>>
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
>>>
>>> JIRA and draft implementation:
>>> https://issues.apache.org/jira/browse/CASSANDRA-18397
>>>
>>> Up-to-date documentation:
>>>
>>> https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
>>>
>>> Discussion:
>>> https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
>>>
>>> The vote will be open for 72 hours.
>>> A vote passes if there are at least three binding +1s and no binding
>>> vetoes.
>>>
>>> Thanks,
>>> Branimir
>>>
>>
>>

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Andrés de la Peña]

+1

On Tue, 4 Apr 2023 at 15:09, Jeremy Hanna 
wrote:

> +1 nb, will be great to have this in the codebase - it will make nearly
> every table's compaction work more efficiently.  The only possible
> exception is tables that are well suited for TWCS.
>
> On Apr 4, 2023, at 8:00 AM, Berenguer Blasi 
> wrote:
>
> +1
> On 4/4/23 14:36, J. D. Jordan wrote:
>
> +1
>
> On Apr 4, 2023, at 7:29 AM, Brandon Williams 
>  wrote:
>
> 
> +1
>
> On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:
>
>> Hi everyone,
>>
>> I would like to put CEP-26 to a vote.
>>
>> Proposal:
>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
>>
>> JIRA and draft implementation:
>> https://issues.apache.org/jira/browse/CASSANDRA-18397
>>
>> Up-to-date documentation:
>>
>> https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
>>
>> Discussion:
>> https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
>>
>> The vote will be open for 72 hours.
>> A vote passes if there are at least three binding +1s and no binding
>> vetoes.
>>
>> Thanks,
>> Branimir
>>
>
>

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Jeremy Hanna]

+1 nb, will be great to have this in the codebase - it will make nearly every 
table's compaction work more efficiently.  The only possible exception is 
tables that are well suited for TWCS.

> On Apr 4, 2023, at 8:00 AM, Berenguer Blasi  wrote:
> 
> +1
> 
> On 4/4/23 14:36, J. D. Jordan wrote:
>> +1
>> 
>>> On Apr 4, 2023, at 7:29 AM, Brandon Williams  
>>>  wrote:
>>> 
>>> 
>>> +1
>>> 
>>> On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov >> > wrote:
 Hi everyone,
 
 I would like to put CEP-26 to a vote.
 
 Proposal:
 https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
 
 JIRA and draft implementation:
 https://issues.apache.org/jira/browse/CASSANDRA-18397
 
 Up-to-date documentation:
 https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
 
 Discussion:
 https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
 
 The vote will be open for 72 hours.
 A vote passes if there are at least three binding +1s and no binding 
 vetoes.
 
 Thanks,
 Branimir

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Jacek Lewandowski]

+1

- - -- --- -  -
Jacek Lewandowski


wt., 4 kwi 2023 o 15:01 Berenguer Blasi 
napisał(a):

> +1
> On 4/4/23 14:36, J. D. Jordan wrote:
>
> +1
>
> On Apr 4, 2023, at 7:29 AM, Brandon Williams 
>  wrote:
>
> 
> +1
>
> On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:
>
>> Hi everyone,
>>
>> I would like to put CEP-26 to a vote.
>>
>> Proposal:
>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
>>
>> JIRA and draft implementation:
>> https://issues.apache.org/jira/browse/CASSANDRA-18397
>>
>> Up-to-date documentation:
>>
>> https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
>>
>> Discussion:
>> https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
>>
>> The vote will be open for 72 hours.
>> A vote passes if there are at least three binding +1s and no binding
>> vetoes.
>>
>> Thanks,
>> Branimir
>>
>

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Berenguer Blasi]

+1

On 4/4/23 14:36, J. D. Jordan wrote:

+1


On Apr 4, 2023, at 7:29 AM, Brandon Williams  wrote:


+1

On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:

Hi everyone,

I would like to put CEP-26 to a vote.

Proposal:

https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy

JIRA and draft implementation:
https://issues.apache.org/jira/browse/CASSANDRA-18397

Up-to-date documentation:

https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md

Discussion:
https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b

The vote will be open for 72 hours.
A vote passes if there are at least three binding +1s and no
binding vetoes.

Thanks,
Branimir

Re: [VOTE] CEP-26: Unified Compaction Strategy

[J. D. Jordan]

+1On Apr 4, 2023, at 7:29 AM, Brandon Williams  wrote:+1On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:Hi everyone,I would like to put CEP-26 to a vote.Proposal:https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+StrategyJIRA and draft implementation:https://issues.apache.org/jira/browse/CASSANDRA-18397Up-to-date documentation:https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.mdDiscussion:https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4bThe vote will be open for 72 hours.A vote passes if there are at least three binding +1s and no binding vetoes.Thanks,Branimir

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Brandon Williams]

+1

On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:

> Hi everyone,
>
> I would like to put CEP-26 to a vote.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
>
> JIRA and draft implementation:
> https://issues.apache.org/jira/browse/CASSANDRA-18397
>
> Up-to-date documentation:
>
> https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
>
> Discussion:
> https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
>
> The vote will be open for 72 hours.
> A vote passes if there are at least three binding +1s and no binding
> vetoes.
>
> Thanks,
> Branimir
>

[VOTE] CEP-26: Unified Compaction Strategy

[Branimir Lambov]

Hi everyone,

I would like to put CEP-26 to a vote.

Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy

JIRA and draft implementation:
https://issues.apache.org/jira/browse/CASSANDRA-18397

Up-to-date documentation:
https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md

Discussion:
https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b

The vote will be open for 72 hours.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thanks,
Branimir

[DISCUSS] CEP-29 CQL NOT Operator

[Piotr Kołaczkowski]

Hi everyone!

I created a new CEP for adding NOT support to the query language and
want to start discussion around it:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator

Happy to get your feedback.
--
Piotr

[ANNOUNCE] Apache Cassandra 4.0.9 test artifact available

[Miklosovic, Stefan]

Based on this thread (1) I want to initiate the release process of 4.0.9.

The test build of Cassandra 4.0.9 is available.

sha1: 99f62b7338fc97a150e52e285f4eee3c636d6637
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.9-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1285/org/apache/cassandra/cassandra-all/4.0.9/

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.0.9/

A vote of this test build will be initiated within the next couple of days.

(1) https://lists.apache.org/thread/zzmz43brtjv5rpx22xbw16nnmtyvdl6q
[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.9-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.9-tentative