In trunk that durability comes from the metadata log, the system_schema tables are only maintained for backwards compatibility (i.e. downgrades) and for drivers.
> On 21 Feb 2025, at 00:29, Jeff Jirsa <jji...@gmail.com> wrote: > > The schema has to be durable on disk for cold start > > You could put a virtual facade in front of it for drivers but you need a > durable physical copy of that schema somewhere, right? > >> On Feb 20, 2025, at 3:57 PM, Bernardo Botella <conta...@bernardobotella.com> >> wrote: >> >> Hi everyone! >> >> As part of Jira ticket (CASSANDRA-20331) involving creating a new system >> table to improve Cosntraints support on the driver, I have been pointed to >> this other Jira (CASSANDRA-19129). It makes perfect sense for us to move to >> virtual tables, and avoid increasing the snowball of tables that will need >> to be migrated. So I think it's a good time to plan on moving these tables. >> Now, for doing so, I see two different approaches: >> - Moving all the tables at once and making sure the driver can find them. >> - We take an incremental approach of moving one by one table. >> >> I wanted to pick this list brains on what are the potential concerns of any >> of those two approaches, and if is there any preference. Or, even better, if >> someone has already thought about a better one. >> >> In my opinion, being able to split the work in the different tables will >> help us spread the work load in a less dramatic path. Unless it becomes a >> burden for the actual client that is, I think we'd be better off migrating >> them one by one to become virtual tables. >> >> Regards, >> Bernardo
