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-the-things(see item 1) 3. Migrating schema because of 1 and 2 4th bonus issue. Grokking consistency level. "EACH_QUORUM sounds perfect for me." I was trying to remember when SCHEMA got added to the CQL parser. With a quick 'git blame' I was taken back to this beast: https://issues.apache.org/jira/browse/CASSANDRA-14825 One huge area that was never addressed in the Jira: any documentation that the official CQL parser now supported SCHEMA. So if anything, we should use this opportunity to update some docs. Patrick On Thu, Apr 6, 2023 at 5:28 PM Dinesh Joshi <djo...@apache.org> wrote: > I’m strongly in favor of leaving terminology as-is. > > On Apr 6, 2023, at 7:20 AM, Bowen Song via dev <dev@cassandra.apache.org> > 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: > > 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 the reason for the discussion, TABLEGROUP doesn't sit > well because of user types / functions / indexes etc. which are not > strictly tables and is also yet another Cassandra only term. > > NAMESPACE could work but it's different usage in other systems could be > just as confusing to new users. > > And, I certainly don't think having multiple names for the same thing just > to satisfy different parties is a good idea at all. > > I'm quite happy to leave things as they are if that is the consensus. > > On Thu, 6 Apr 2023 at 14:16, Josh McKenzie <jmcken...@apache.org> 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 and SCHEMA are actually fine enough. >> >> If and when we get to any kind of multi-tenancy, having a more >> metaphorical abstraction that users are familiar with like these becomes >> more valuable; it's pretty clear that things in different keyspaces, >> different databases, or even different schemas could have different access >> rules, resourcing, etc from one another. >> >> While the off-the-cuff logical TABLEGROUP thing is a *literal* statement >> about what the thing is, it'd be another unique term to us; we have enough >> things in our system where we've charted our own path. My personal .02 is >> we don't need to go adding more. :) >> >> On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever wrote: >> >> >> … 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 best idea is on >> the tail end of a sequence of bad and/or unpopular ideas. >> >> >> >> >> >> > > -- > [image: DataStax Logo Square] <https://www.datastax.com/> *Mike Adamson* > Engineering > > +1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/> > Find DataStax Online: [image: LinkedIn Logo] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> > [image: Facebook Logo] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> > [image: Twitter Logo] <https://twitter.com/DataStax> [image: RSS > Feed] <https://www.datastax.com/blog/rss.xml> [image: Github Logo] > <https://github.com/datastax> > >
