> > "Make the scan faster" > "Make the scan incremental and automatic" > "Make it not blow up your page cache" > "Make losing your base replicas less likely". > > There's a concrete, real opportunity with MVs to create integrity > assertions we're missing. A dangling record from an MV that would point to > missing base data is something that could raise alarm bells and signal > JIRAs so we can potentially find and fix more surprise edge cases. >
I agree with Jeff that there is some stuff to do to address the current MV issues and I am willing to focus on making them production ready. On Wed, Jul 1, 2020 at 2:58 AM <joshua.mcken...@gmail.com> wrote: > It would be incredibly helpful for us to have some empirical data and > agreed upon terms and benchmarks to help us navigate discussions like this: > > * How widely used is a feature in C* deployments worldwide? > * What are the primary issues users face when deploying them? Scaling > them? During failure scenarios? > * What does the engineering effort to bridge these gaps look like? Who > will do that? On what time horizon? > * What does our current test coverage for this feature look like? > * What shape of defects are arising with the feature? In a specific > subsection of the module or usage? > * Do we have an agreed upon set of standards for labeling a feature > stable? As experimental? If not, how do we get there? > * What effort will it take to bridge from where we are to where we agree > we need to be? On what timeline is this acceptable? > > I believe these are not only answerable questions, but fundamentally the > underlying themes our discussion alludes to. They’re also questions that > apply to a lot more than just MV’s and tie into what you’re speaking to > above Benedict. > > > > On Jun 30, 2020, at 8:32 PM, sankalp kohli <kohlisank...@gmail.com> > wrote: > > > > I see this discussion as several decisions which can be made in small > > increments. > > > > 1. In release cycles, when can we propose a feature to be deprecated or > > marked experimental. Ideally a new feature should come out experimental > if > > required but we have several who are candidates now. We can work on > > integrating this in the release lifecycle doc we already have. > > 2. What is the process of making an existing feature experimental? How > does > > it affect major releases around testing. > > 3. What is the process of deprecating/removing an experimental feature. > > (Assuming experimental features should be deprecated/removed) > > > > Coming to MV, I think we need more data before we can say we > > should deprecate MV. Here are some of them which should be part of > > deprecation process > > 1.Talk to customers who use them and understand what is the impact. Give > > them a forum to talk about it. > > 2. Do we have enough resources to bring this feature out of the > > experimental feature list in next 1 or 2 major releases. We cannot have > too > > many experimental features in the database. Marking a feature > experimental > > should not be a parking place for a non functioning feature but a place > > while we stabilize it. > > > > > > > > > >> On Tue, Jun 30, 2020 at 4:52 PM <joshua.mcken...@gmail.com> wrote: > >> > >> I followed up with the clarification about unit and dtests for that > reason > >> Dinesh. We test experimental features now. > >> > >> If we’re talking about adding experimental features to the 40 quality > >> testing effort, how does that differ from just saying “we won’t release > >> until we’ve tested and stabilized these features and they’re no longer > >> experimental”? > >> > >> Maybe I’m just misunderstanding something here? > >> > >>>> On Jun 30, 2020, at 7:12 PM, Dinesh Joshi <djo...@apache.org> wrote: > >>> > >>> > >>>> > >>>> On Jun 30, 2020, at 4:05 PM, Brandon Williams <dri...@gmail.com> > wrote: > >>>> > >>>> Instead of ripping it out, we could instead disable them in the yaml > >>>> with big fat warning comments around it. That way people already > >>>> using them can just enable them again, but it will raise the bar for > >>>> new users who ignore/miss the warnings in the logs and just use them. > >>> > >>> Not a bad idea. Although, the real issue is that users enable MV on a 3 > >> node cluster with a few megs of data and conclude that MVs will > >> horizontally scale with the size of data. This is what causes issues for > >> users who naively roll it out in production and discover that MVs do not > >> scale with their data growth. So whatever we do, the big fat warning > should > >> educate the unsuspecting operator. > >>> > >>> Dinesh > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
