Re: [DISCUSS] Removing support for deterministic table IDs

5.0 and trunk patches are up in CASSANDRA-19809 if anyone is interested in reviewing. On Wed, Jul 31, 2024 at 1:55 PM Jeff Jirsa wrote: > Would also vote to remove when TCM is available/stable. > > More words on the create, drop, re-create,

Re: [DISCUSS] Removing support for deterministic table IDs

Would also vote to remove when TCM is available/stable. More words on the create, drop, re-create, in case it’s not familiar to people: - Create assigns an ID - Drop removes definition and data - Create assigns an ID If non-deterministic, we had races where an ID was assigned concurrently in tw

Re: [DISCUSS] Removing support for deterministic table IDs

> what’s the motivation for removal? One thing that also makes it better to remove is that this adds the ABA problem into our tables, where as removing it fixes that… If you create a table “foo”, drop it, then recreate “foo”, the 2 “foo” tables share the same tableId, which can trick things to

Re: [DISCUSS] Removing support for deterministic table IDs

Understood. Nits aside I have no objection to your plan. Jordan On Tue, Jul 30, 2024 at 15:42 Caleb Rackliffe wrote: > I think the main motivation for ignoring the YAML option and removing > down the line is that we probably never would have created it if TCM > existed at that point of creation

Re: [DISCUSS] Removing support for deterministic table IDs

I think the main motivation for ignoring the YAML option and removing down the line is that we probably never would have created it if TCM existed at that point of creation. I'd liken it to what we did w/ some no-longer-relevant options for the batch commit log. On Tue, Jul 30, 2024 at 5:19 PM Jor

Re: [DISCUSS] Removing support for deterministic table IDs

Generally no disagreement but more of a curiosity: what’s the motivation for removal? Just that it’s not needed? Otherwise it’s relatively cheap and DDL aren’t high throughput (or at least shouldn’t be since we can only deal with so many tables) Jordan On Tue, Jul 30, 2024 at 15:04 Caleb Rackliff

Re: [DISCUSS] Removing support for deterministic table IDs

To summarize all this noise I've created, the plan would be... 1.) Leave CQL WITH id intact. 2.) Deprecate and WARN on *use_deterministic_table_id *in 5.0.x. 3.) Ignore and WARN on *use_deterministic_table_id *in 5.1. 4.) Profit On Tue, Jul 30, 2024 at 4:46 PM Caleb Rackliffe wrote: > No intent

Re: [DISCUSS] Removing support for deterministic table IDs

No intention of touching WITH id in CQL On Tue, Jul 30, 2024 at 4:10 PM Caleb Rackliffe wrote: > To clarify, my plan was to deprecate in Config/JMX and ignore it, not > remove it entirely so it breaks existing YAMLs and JMX clients. > > This should be fine, if I'm reading the upgrade notes corre

Re: [DISCUSS] Removing support for deterministic table IDs

To clarify, my plan was to deprecate in Config/JMX and ignore it, not remove it entirely so it breaks existing YAMLs and JMX clients. This should be fine, if I'm reading the upgrade notes correctly, as no table or view creation operations will be allowed on 5.1 nodes until upgrade is complete and

Re: [DISCUSS] Removing support for deterministic table IDs

+1 to deprecate it. What does removing it buy us? > On Jul 30, 2024, at 3:52 PM, David Capwell wrote: > > Users can provide ids and TCM can manage to make them safe, so agree we > don’t really need the feature anymore. I am fine with deprecating the > feature, but removing would be a breakin

Re: [DISCUSS] Removing support for deterministic table IDs

Users can provide ids and TCM can manage to make them safe, so agree we don’t really need the feature anymore. I am fine with deprecating the feature, but removing would be a breaking change for anyone that had that config in place, so not a fan of breaking the config interface. > On Jul 30, 2

[DISCUSS] Removing support for deterministic table IDs

I'd like to propose removing deterministic table IDs for new *user* tables and views in trunk. With TCM in place, it looks like the reason we added *use_deterministic_table_id*, concurrent table creations, is no longer a concern. Thoughts? Objections?