> > This was since extended to also support ALLOW FILTERING mode as well as OR > with clustering key columns.
If the code is able to support query using clustering columns without the need for filtering + filtering queries then it should be relatively easy to have full support for CQL. We also need some proper test coverage and ideally some validation with Harry. * Since OR support nevertheless is a feature of SAI, it needs to be at > least unit tested, but ideally even would be exposed so that it is possible > to test on the CQL level. Is there some mechanism such as experimental > flags, which would allow the SAI-only OR support to be merged into trunk, > while a separate CEP is focused on implementing "proper" general purpose OR > support? I should note that there is no guarantee that the OR CEP would be > implemented in time for the next release. So the answer to this point needs > to be something that doesn't violate the desire for good user experience. > This is currently what we have with SASI. Currently SASI is behind an experimental flag but nevertheless the LIKE restriction code has been introduced as part of the code base and its use will result in an error without a SASI index. SASI has been there for multiple years and we still do not support LIKE restrictions for other use cases. I am against that approach because I do believe that it is what has led us where we are today. We need to stop adding bits of CQL grammar to fulfill the need of a given feature and start considering CQL as a whole. I am in favor of moving forward with SAI without OR support until OR can be properly added to CQL. Le lun. 7 févr. 2022 à 13:11, Henrik Ingo <henrik.i...@datastax.com> a écrit : > Thanks Benjamin for reviewing and raising this. > > While I don't speak for the CEP authors, just some thoughts from me: > > On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer <ble...@apache.org> wrote: > >> I would like to raise 2 points regarding the current CEP proposal: >> >> 1. There are mention of some target versions and of the removal of SASI >> >> At this point, we have not agreed on any version numbers and I do not >> feel that removing SASI should be part of the proposal for now. >> It seems to me that we should see first the adoption surrounding SAI >> before talking about deprecating other solutions. >> >> > This seems rather uncontroversial. I think the CEP template and previous > CEPs invite the discussion on whether the new feature will or may replace > an existing feature. But at the same time that's of course out of scope for > the work at hand. I have no opinion one way or the other myself. > > > >> 2. OR queries >> >> It is unclear to me if the proposal is about adding OR support only for >> SAI index or for other types of queries too. >> In the past, we had the nasty habit for CQL to provide only partialially >> implemented features which resulted in a bad user experience. >> Some examples are: >> * LIKE restrictions which were introduced for the need of SASI and were >> not never supported for other type of queries >> * IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported >> elsewhere >> * != operator only supported for conditional inserts or updates >> And there are unfortunately many more. >> >> We are currenlty slowly trying to fix those issue and make CQL a more >> mature language. By consequence, I would like that we change our way of >> doing things. If we introduce support for OR it should also cover all the >> other type of queries and be fully tested. >> I also believe that it is a feature that due to its complexity fully >> deserves its own CEP. >> >> > The current code that would be submitted for review after the CEP is > adopted, contains OR support beyond just SAI indexes. An initial > implementation first targeted only such queries where all columns in a > WHERE clause using OR needed to be backed by an SAI index. This was since > extended to also support ALLOW FILTERING mode as well as OR with clustering > key columns. The current implementation is by no means perfect as a general > purpose OR support, the focus all the time was on implementing OR support > in SAI. I'll leave it to others to enumerate exactly the limitations of the > current implementation. > > Seeing that also Benedict supports your point of view, I would steer the > conversation more into a project management perspective: > * How can we advance CEP-7 so that the bulk of the SAI code can still be > added to Cassandra, so that users can benefit from this new index type, > albeit without OR? > * This is also an important question from the point of view that this is a > large block of code that will inevitably diverged if it's not in trunk. > Also, merging it to trunk will allow future enhancements, including the OR > syntax btw, to happen against trunk (aka upstream first). > * Since OR support nevertheless is a feature of SAI, it needs to be at > least unit tested, but ideally even would be exposed so that it is possible > to test on the CQL level. Is there some mechanism such as experimental > flags, which would allow the SAI-only OR support to be merged into trunk, > while a separate CEP is focused on implementing "proper" general purpose OR > support? I should note that there is no guarantee that the OR CEP would be > implemented in time for the next release. So the answer to this point needs > to be something that doesn't violate the desire for good user experience. > > henrik > > >
