Somebody correct me if I am wrong but "partition key" itself is not enough (primary keys = partition keys + clustering columns). It will require ALLOW FILTERING when clustering columns are not specified either.
create table ks.tb (p1 int, c1 int, col1 int, col2 int, primary key (p1, c1)); select * from ks.tb where p1 = 1 and col1 = 2; // this will require allow filtering The documentation seems to omit this fact. ________________________________________ From: Henrik Ingo <henrik.i...@datastax.com> Sent: Thursday, April 13, 2023 8:53 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-29 CQL NOT Operator 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. Wait... Why would anything require ALLOW FILTERING if the partition key is defined? That seems to contradict documentation: https://cassandra.apache.org/doc/latest/cassandra/cql/dml.html#allow-filtering Also my intuition / expectation matches what the manual says. henrik On Fri, Apr 7, 2023 at 12:01 AM Jeremy Hanna <jeremy.hanna1...@gmail.com<mailto:jeremy.hanna1...@gmail.com>> wrote: Considering all of the examples require using ALLOW FILTERING with the partition key specified, I think it's appropriate to consider separating out use of ALLOW FILTERING within a partition versus ALLOW FILTERING across the whole table. A few years back we had a discussion about this in ASF slack in the context of capability restrictions and it seems relevant here. That is, we don't want people to get comfortable using ALLOW FILTERING across the whole table. However, there are times when ALLOW FILTERING within a partition is reasonable. Ticket to discuss separating them out: https://issues.apache.org/jira/browse/CASSANDRA-15803 Summary: Perhaps add an optional [WITHIN PARTITION] or something similar to make it backwards compatible and indicate that this is purely within the specified partition. This also gives us the ability to disallow table scan types of ALLOW FILTERING from a guard rail perspective, because the intent is explicit. That operators could disallow ALLOW FILTERING but allow ALLOW FILTERING WITHIN PARTITION, or whatever is decided. I do NOT want to hijack a good discussion but I thought this separation could be useful within this context. Jeremy On Apr 6, 2023, at 3:00 PM, Patrick McFadin <pmcfa...@gmail.com<mailto:pmcfa...@gmail.com>> wrote: I love that this is finally coming to Cassandra. Absolutely hate that, once again, we'll be endorsing the use of ALLOW FILTERING. This is an anti-pattern that keeps getting legitimized. Hot take: Should we just not do Milestones 1 and 2 and wait for an index-only Milestone 3? Patrick On Thu, Apr 6, 2023 at 10:04 AM David Capwell <dcapw...@apple.com<mailto:dcapw...@apple.com>> wrote: Overall I welcome this feature, was trying to use this around 1-2 months back and found we didn’t support, so glad to see it coming! From a testing point of view, I think we would want to have good fuzz testing covering complex types (frozen/non-frozen collections, tuples, udt, etc.), and reverse ordering; both sections tend to cause the most problem for new features (and existing ones) We also will want a way to disable this feature, and optionally disable at different sections (such as m2’s NOT IN for partition keys). > On Apr 4, 2023, at 2:28 AM, Piotr Kołaczkowski > <pkola...@datastax.com<mailto:pkola...@datastax.com>> wrote: > > Hi everyone! > > I created a new CEP for adding NOT support to the query language and > want to start discussion around it: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator > > Happy to get your feedback. > -- > Piotr -- [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/>
