Dig deeper :)
It’s existed since day one in both CQL2 and CQL3.
https://github.com/apache/cassandra/blob/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g#L526-L527
> On 10 Apr 2023, at 00:35, Patrick McFadin wrote:
>
> I was trying to remember when SCHEMA got added to the CQL parser. With
Good suggestion Mike. I'm +1 on the idea and agree the name KEYSPACE is
confusing to new users.
Jon
On 2023/04/04 15:48:26 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 a
I love the debate that surfaces occasionally, but I have to agree that
KEYSPACE and SCHEMA are doing the job. There is a learning curve with
Cassandra data modeling, and keywords are a minor problem.
Issues that hit every user:
1. Creating the correct primary key
2. Avoiding the urge to index all-
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:
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
“ 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
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
ind that all nodetool commands which are using "keyspace"
> terminology would have to be probably accommodated to "database" term as well.
>
> ________
> From: Berenguer Blasi
> Sent: Thursday, April 6, 2023 9:47
> To: dev@cassand
>
> 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
oing that? Having 4 ways to
> do that feels like we do not know how to name it.
> >
> > Somebody already mentioned in this thread that Postgres is quite complex
> in this. Maybe adding "DATABASE" would be OK but anything beyond that
> (NAMESPACE etc) is just too mu
much imo.
________
From: Jacek Lewandowski
Sent: Thursday, April 6, 2023 8:36
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless yo
probably accommodated to "database" term as well.
From: Berenguer Blasi
Sent: Thursday, April 6, 2023 9:47
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
NetApp Security WARNING: Thi
beyond that (NAMESPACE etc) is just
too much imo.
From: Jacek Lewandowski
Sent: Thursday, April 6, 2023 8:36
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
NetApp Security WARNING: This is an external email. Do not cli
ay, April 6, 2023 8:36
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Haha... we h
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
Haha... we have opinions against each name :)
According to what Caleb said, I don't think all new users start learning
Cassandra from understanding the replication.
There are probably many small projects where Cassandra is used on a single
node, or bigger projects where people
try different things
either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
NAMESPACE is always used in hbase which is a table store in my mind.
For existing users, NAMESPACE may take some time to be accepted. For hbase
and cassandra users, it may be necessary to mix the corresponding terms.
>From the terminolo
KEYSPACE isn’t a terrible name for a namespace that also configures how keys are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t seem to have the advantages of either.I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to believe KEYSPACE is really a stu
FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can
use CREATE SCHEMA in place of CREATE KEYSPACE, etc.
> On 4 Apr 2023, at 19:23, Henrik Ingo wrote:
>
> I find the Postgres terminology overly complex. Where most SQL databases will
> have several *databases*, each con
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
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
32 matches
Mail list logo
