“ 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 is orthogonal to replication, but that should be a different discussion about how we evolve config.” +1 On Thu, 6 Apr 2023 at 5:26, Benedict <bened...@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 think it would be fine to introduce some arbitrary unrelated concept for > assigning tables with similar behaviours some configuration that is > orthogonal to replication, but that should be a different discussion about > how we evolve config. > > On 6 Apr 2023, at 09:40, Mick Semb Wever <m...@apache.org> wrote: > > > > 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, rf, and durable_writes. If > they also had the table options that could be defined as defaults for all > tables in that group, and one tablegroup could be a child and inherit > settings from another tablegroup, you could logically group tables in ways > that both benefit your application platform's taxonomy and the spread of > keyspace/table settings. DATABASE, NAMESPACE, whatever, can be aliases to > it too, if you like. > > > > >
