> 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.
+1 On Wed, 1 Jul 2020 at 15:42, Benjamin Lerer <benjamin.le...@datastax.com> wrote: > > > > "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 > > > > >
