-1 as well. We need to upgrade Zstd.
>
> On Apr 6, 2023, at 4:57 AM, Mick Semb Wever wrote:
>
>
>
>
>> Up to you to fail the vote and we realistically release 4.0.9 after Easter
>
>
> -1 to the vote.
>
> I support your initial veto and reasoning, and it appears you are willing to
> re
I’m strongly in favor of leaving terminology as-is. On Apr 6, 2023, at 7:20 AM, Bowen Song via dev wrote:
> I'm quite happy to leave things as they are if that is
the consensus.
+1 to the above
On 06/04/2023 14:54, Mike Adamson
wrote:
Considering all of the examples require using ALLOW FILTERING with the
partition key specified, I think it's appropriate to consider separating out
use of ALLOW FILTERING within a partition versus ALLOW FILTERING across the
whole table. A few years back we had a discussion about this in ASF sla
I love that this is finally coming to Cassandra. Absolutely hate that, once
again, we'll be endorsing the use of ALLOW FILTERING. This is an
anti-pattern that keeps getting legitimized.
Hot take: Should we just not do Milestones 1 and 2 and wait for an
index-only Milestone 3?
Patrick
On Thu, Apr
+1
Thanks to Lorina for getting people excited about it at Cassandra Forward!
On Thu, Apr 6, 2023 at 10:37 AM Mick Semb Wever wrote:
> +1
>
> On Thu, 6 Apr 2023 at 19:32, Francisco Guerrero
> wrote:
>
>> +1 (nb)
>>
>> On 2023/04/06 17:30:37 Josh McKenzie wrote:
>> > +1
>> >
>> > On Thu, Apr 6,
+1
On Thu, 6 Apr 2023 at 19:32, Francisco Guerrero wrote:
> +1 (nb)
>
> On 2023/04/06 17:30:37 Josh McKenzie wrote:
> > +1
> >
> > On Thu, Apr 6, 2023, at 12:18 PM, Joseph Lynch wrote:
> > > +1
> > >
> > > This proposal looks really exciting!
> > >
> > > -Joey
> > >
> > > On Wed, Apr 5, 2023 at
+1 (nb)
On 2023/04/06 17:30:37 Josh McKenzie wrote:
> +1
>
> On Thu, Apr 6, 2023, at 12:18 PM, Joseph Lynch wrote:
> > +1
> >
> > This proposal looks really exciting!
> >
> > -Joey
> >
> > On Wed, Apr 5, 2023 at 2:13 AM Aleksey Yeshchenko wrote:
> > >
> > > +1
> > >
> > > On 4 Apr 2023, at 16
+1
On Thu, Apr 6, 2023, at 12:18 PM, Joseph Lynch wrote:
> +1
>
> This proposal looks really exciting!
>
> -Joey
>
> On Wed, Apr 5, 2023 at 2:13 AM Aleksey Yeshchenko wrote:
> >
> > +1
> >
> > On 4 Apr 2023, at 16:56, Ekaterina Dimitrova wrote:
> >
> > +1
> >
> > On Tue, 4 Apr 2023 at 11:44,
Overall I welcome this feature, was trying to use this around 1-2 months back
and found we didn’t support, so glad to see it coming!
From a testing point of view, I think we would want to have good fuzz testing
covering complex types (frozen/non-frozen collections, tuples, udt, etc.), and
rever
+1
This proposal looks really exciting!
-Joey
On Wed, Apr 5, 2023 at 2:13 AM Aleksey Yeshchenko wrote:
>
> +1
>
> On 4 Apr 2023, at 16:56, Ekaterina Dimitrova wrote:
>
> +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
On Thu, Apr 6, 2023 at 4:16 PM Josh McKenzie wrote:
> KEYSPACE is fine. If we want to introduce a standard nomenclature like
> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
> benefit.
>
> I'm with Benedict in principle, with Aleksey in practice; I think KEYSPACE
> an
/> I'm quite happy to leave things as they are if that is the consensus./
+1 to the above
On 06/04/2023 14:54, Mike Adamson wrote:
My apologies. I started this discussion off the back of a usability
discussion around new user accessibility to Cassandra and the premise
that there is an initial
My apologies. I started this discussion off the back of a usability
discussion around new user accessibility to Cassandra and the premise that
there is an initial steep learning curve for new users. Including new users
who have worked for a long time in the traditional DBMS field.
On the basis of
> KEYSPACE is fine. If we want to introduce a standard nomenclature like
> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
> benefit.
I'm with Benedict in principle, with Aleksey in practice; I think KEYSPACE and
SCHEMA are actually fine enough.
If and when we get to
> … but that should be a different discussion about how we evolve config.
>
I disagree. Nomenclature being difficult can benefit from holistic and
forward thinking.
Sure you can label this off-topic if you like, but I value our discuss
threads being collaborative in an open-mode. Sometimes the b
> Up to you to fail the vote and we realistically release 4.0.9 after Easter
>
-1 to the vote.
I support your initial veto and reasoning, and it appears you are willing
to recut once 18429 is resolved.
“ KEYSPACE is fine. If we want to introduce a standard nomenclature like
DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
benefit.
I think it would be fine to introduce some arbitrary unrelated concept for
assigning tables with similar behaviours some configuration that
1.5.5 was just released.
I am bumping it under this ticket
https://issues.apache.org/jira/browse/CASSANDRA-18429
I am building CI as we speak.
Up to you to fail the vote and we realistically release 4.0.9 after Easter
From: Miklosovic, Stefan
Sent: Wed
KEYSPACE is fine. If we want to introduce a standard nomenclature like DATABASE
that’s also fine. Inventing brand new ones is not fine, there’s no benefit.
I think it would be fine to introduce some arbitrary unrelated concept for
assigning tables with similar behaviours some configuration that
I just do not share your concerns, Berenguer. Maybe you have a different
experience but I have never seen anybody who judged if they are going to use so
and so database based on the fact if the startup logs are easy to parse,
conceptually and mentally. Lets talk about simplifying the startup log
>
> 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.
>
TABLEGROUP would work for me. Immediately intuitive.
brain-storming…
A keyspace today defines replication strategy
>
> So lets rename Keyspace (Java class) to Database then. If we are concerned
> that looking into logs would be full of "keyspaces" but a user created
> "database" and it is a source of inconsistencies, should not it be somehow
> resolved and unified?
>
> I think that it is just too late to rename
No beginner is going to look for keyspace in logs imo, that's not what I
was pointing at. But upon starting C* you get a wall of logs which is
less user friendly imo than having a nice simple message saying you just
started. Then you go to cqlsh and keyspace and RF are the first things
he is go
So lets rename Keyspace (Java class) to Database then. If we are concerned that
looking into logs would be full of "keyspaces" but a user created "database"
and it is a source of inconsistencies, should not it be somehow resolved and
unified?
I think that it is just too late to rename keyspace
One aspect to take into account is that we might not go even get as far
as having a chance to educate the user. They start the thing up, see a
wall of logs and then start seeing 'keyspace' (what is that?), etc.
Everything seems so foreign and out of band to their 'normal' experience
they just m
I am against simplifying that so much, up to the point that there is some
implicit replication strategy. While I understand the preferences towards
having it all "easier", what is wrong with knowing that there are some
replication strategies and my data will be replicated just once? There is als
I think replication_factor or replication is important😄. This concepts
will correspondingly lead to the concept of read and write consistency(ie :
ONE/QUORUM/ALL and so on) that users need to care about.
And the consistency level is very important to cassandra in my opinion.
Our experience is that
27 matches
Mail list logo
