Re: Google Season of Docs

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

Re: Google Season of Docs

  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:

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

+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

[DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

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

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

+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

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

+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

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

+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:

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

+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: >

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

+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:

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

+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

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

+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: >

[VOTE] CEP-26: Unified Compaction Strategy

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:

[DISCUSS] CEP-29 CQL NOT Operator

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

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: