For everyone previously following this, just created https://issues.apache.org/jira/browse/CASSANDRA-18615 :)
On Fri, May 19, 2023 at 1:34 PM Caleb Rackliffe <calebrackli...@gmail.com> wrote: > Posted on ASF Slack to see if we can get more responses, but so far the > leaders seem to be... > > [POLL] Centralize existing syntax or create new syntax? > > 1.) CREATE INDEX ... USING ... WITH OPTIONS... > > (i.e. centralize) > > [POLL] Should there be a default? (YES/NO) > > Yes > > [POLL] What do do with the default? > > 3.) and 4.) i.e. YAML options to control default and requirement to > specify a default > > (i.e. w/o changing default in 5.0) > > On Thu, May 18, 2023 at 3:33 AM Miklosovic, Stefan < > stefan.mikloso...@netapp.com> wrote: > >> I don't want to hijack this thread, I just want to say that the point 4) >> seems to be recurring. I second Caleb in saying that transactional metadata >> would probably fix this. Because of the problem of not being sure that all >> config is same, cluster-wide, I basically dropped the effort on CEP-24 >> because different local configurations might compromise the security. >> >> ________________________________________ >> From: Henrik Ingo <henrik.i...@datastax.com> >> Sent: Wednesday, May 17, 2023 22:32 >> To: dev@cassandra.apache.org >> Subject: Re: [DISCUSS] The future of CREATE INDEX >> >> 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. >> >> >> >> I have read the thread but chose to reply to the top message... >> >> I'm coming to this with the background of having worked with MySQL, where >> both the storage engine and index implementation had many options, and >> often of course some index types were only available in some engines. >> >> I would humbly suggest: >> >> 1. What's up with naming anything "legacy". Calling the current index >> type "2i" seems perfectly fine with me. From what I've heard it can work >> great for many users? >> >> 2. It should be possible to always specify the index type explicitly. In >> other words, it should be possible to CREATE CUSTOM INDEX ... USING "2i" >> (if it isn't already) >> >> 2b) It should be possible to just say "SAI" or "SASIIndex", not the full >> Java path. >> >> 3. It's a fair point that the "CUSTOM" word may make this sound a bit too >> special... The simplest change IMO is to just make the CUSTOM work optional. >> >> 4. Benedict's point that a YAML option is per node is a good one... For >> example, you wouldn't want some nodes to create a 2i index and other nodes >> a SAI index for the same index.... That said, how many other YAML options >> can you think of that would create total chaos if different nodes actually >> had different values for them? For example what if a guardrail allowed some >> action on some nodes but not others? Maybe what we need is a jira ticket >> to enforce that certain sections of the config must not differ? >> >> 5. That said, the default index type could also be a property of the >> keyspace >> >> 6. MySQL allows the DBA to determine the default engine. This seems to >> work well. If the user doesn't care, they don't care, if they do, they use >> the explicit syntax. >> >> henrik >> >> >> On Wed, May 10, 2023 at 12:45 AM Caleb Rackliffe < >> calebrackli...@gmail.com<mailto:calebrackli...@gmail.com>> wrote: >> Earlier today, Mick started a thread on the future of our index creation >> DDL on Slack: >> >> https://the-asf.slack.com/archives/C018YGVCHMZ/p1683527794220019< >> https://urldefense.com/v3/__https://the-asf.slack.com/archives/C018YGVCHMZ/p1683527794220019__;!!PbtH5S7Ebw!YuQzuQkxC0gmD9ofXEGoaEmVMwPwZ_ab8-B_PCfRfNsQtKIZDLOIuw38jnV1Vt8TqHXn-818hL-CoLbVJXBTCWgSxoE$ >> > >> >> At the moment, there are two ways to create a secondary index. >> >> 1.) CREATE INDEX [IF NOT EXISTS] [name] ON <table> (<column>) >> >> This creates an optionally named legacy 2i on the provided table and >> column. >> >> ex. CREATE INDEX my_index ON kd.tbl(my_text_col) >> >> 2.) CREATE CUSTOM INDEX [IF NOT EXISTS] [name] ON <table> (<column>) >> USING <class|alias> [WITH OPTIONS = <options>] >> >> This creates a secondary index on the provided table and column using the >> specified 2i implementation class and (optional) parameters. >> >> ex. CREATE CUSTOM INDEX my_index ON ks.tbl(my_text_col) USING >> 'StorageAttachedIndex' >> >> (Note that the work on SAI added aliasing, so `StorageAttachedIndex` is >> shorthand for the fully-qualified class name, which is also valid.) >> >> So what is there to discuss? >> >> The concern Mick raised is... >> >> "...just folk continuing to use CREATE INDEX because they think CREATE >> CUSTOM INDEX is advanced (or just don't know of it), and we leave users >> doing 2i (when they think they are, and/or we definitely want them to be, >> using SAI)" >> >> To paraphrase, we want people to use SAI once it's available where >> possible, and the default behavior of CREATE INDEX could be at odds w/ that. >> >> The proposal we seem to have landed on is something like the following: >> >> For 5.0: >> >> 1.) Disable by default the creation of new legacy 2i via CREATE INDEX. >> 2.) Leave CREATE CUSTOM INDEX...USING... available by default. >> >> (Note: How this would interact w/ the existing secondary_indexes_enabled >> YAML options isn't clear yet.) >> >> Post-5.0: >> >> 1.) Deprecate and eventually remove SASI when SAI hits full feature >> parity w/ it. >> 2.) Replace both CREATE INDEX and CREATE CUSTOM INDEX w/ something of a >> hybrid between the two. For example, CREATE INDEX...USING...WITH. This >> would both be flexible enough to accommodate index implementation selection >> and prescriptive enough to force the user to make a decision (and wouldn't >> change the legacy behavior of the existing CREATE INDEX). In this world, >> creating a legacy 2i might look something like CREATE INDEX...USING >> `legacy`. >> 3.) Eventually deprecate CREATE CUSTOM INDEX...USING. >> >> Eventually we would have a single enabled DDL statement for index >> creation that would be minimal but also explicit/able to handle some >> evolution. >> >> What does everyone think? >> >> >> -- >> >> [ >> https://lh5.googleusercontent.com/UwlCp-Ixn21QzYv9oNnaGy0cKfFk1ukEBVKSv4V3-nQShsR-cib_VeSuNm4M_xZxyAzTTr0Et7MsQuTDhUGcmWQyfVP801Flif-SGT2x38lFRGkgoMUB4cot1DB9xd7Y0x2P0wJWA-gQ5k4rzytFSoLCP4wJntmJzhlqTuQQsOanCBHeejtSBcBry5v6kw >> ] >> >> Henrik Ingo >> >> c. +358 40 569 7354 >> >> w. www.datastax.com<http://www.datastax.com> >> >> [ >> https://lh3.googleusercontent.com/T6MEp9neZySKd-eg-tkz96Yf4qG_Xsgu-IznDkdHfsHCjAnnHQP6OsPCdj8rsDvgKs-GJS6TA7Yx5HlK-zfRlE64j0zDpDG9cI29VaG948x5xLgUU4KKctaHNAhbpJ_pDwzRag9K7yCibGblB5Ix5z6Xj99Vc92V9nYSmR4HIj5F9T_TVI7ayW2n2_lp5Q >> ]<https://www.facebook.com/datastax> [ >> https://lh3.googleusercontent.com/Xrju2UthJiMtMS5jFknV8AhVO45tfhXSR6U0F8Qam1Mu2taE2SeVcl5ExaxU5l6pG0fHjv2b6vvUOe12WQldMqsOHknC7wQtBVYiX9ff3fLMtFAbjVRM0MGTKvPsjAcMI_FNvcIcuWIBP_zwRuh3b3g6hjHOW0ik9bDPuuYMvdLWIF8C8YgKDYQ-nV9dlQ] >> <https://twitter.com/datastax> [ >> https://lh5.googleusercontent.com/OS41kMrzmJhmkvdmkHU-pq69Nzy1tOz36NIwGs61oz9cGj42TTggsXk58MY1Lqn5FyIK77jedKh3UN-1RMCgCqduMQeUNU5fVKjCBNvSOpp6NjBLZp-2NMypQnw7JoyPoeI_iXfygfzquE89GLoel7Tiq1Jtz6ueaaVA9goEhUn2rWIJMQ28DPrEj4xqfg] >> <https://www.linkedin.com/company/datastax/> [ >> https://lh3.googleusercontent.com/AVBOsupbzcVirw6fNWEIerGj-CT9XuzDmGpAa5KimxCLGAICw7_TV040RngH0I_0Z9ZEWERsQOiCSqD4ORslxJdqFiuFc1qgIoA9QMXW_yRklRJrrrCO0rQ47Hvt9QtfAz7swR_Vn6N8wZPYE2APUJAo-oB_X71omearuZFBjL9VKbhbrZXn9HQ7aGSxIA] >> <https://github.com/datastax/> >> >>
