Given this discussion +1 from me to move OR to its own CEP separate from the new index implementation.
> On Feb 7, 2022, at 6:51 AM, Benjamin Lerer <b.le...@gmail.com> wrote: > > >> 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 >> >>
