As Scott Andreas mentioned in cassandra-dev slack, Zstd folks just fixed a very
rare data corruption bug in zstd 1.5.4 and they released 1.5.5 literally 8
hours ago (1). Java zstd library we use seem to incorporate these changes like
an hour ago (2) but there is no release yet. I am expecting th
>
> The vote will be open for 72 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
Checked
- signing correct
- checksums are correct
- source art
Proposing the test build of Cassandra 4.0.9 for release.
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/
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 yo
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:
Sadl
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 namespac
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 Xa
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
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 u
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.
Some
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 "namespa
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
user
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/0
+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 compactio
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 DATA
+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
+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
+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
- - -- --- - -
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:
>
+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
+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 implem
+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
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/cass
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
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://repos
25 matches
Mail list logo