+1 on marking MVs experimental, but should there be some point in the future where we consider removing them from the code base unless they have gotten significant improvement as well?
We probably need to enforce some kind of process for adding new experimental features in the future - perhaps a mail like this one to dev@ motivating why it should be experimental? /Marcus On Sat, Sep 30, 2017 at 1:15 AM, Vinay Chella <vche...@netflix.com.invalid> wrote: > We tried perf testing MVs internally here but did not see good results with > it, hence paused its usage. +1 on tagging certain features which are not > PROD ready or not stable enough. > > Regards, > Vinay Chella > > On Fri, Sep 29, 2017 at 7:22 PM, Ben Bromhead <b...@instaclustr.com> wrote: > > > I'm a fan of introducing experimental flags in general as well, +1 > > > > > > > > On Fri, 29 Sep 2017 at 13:22 Jon Haddad <j...@jonhaddad.com> wrote: > > > > > I’m very much +1 on this, and to new features in general. > > > > > > I think having a clear line in which we classify something as > production > > > ready would be nice. It would be great if committers were using the > > > feature in prod and could vouch for it’s stability. > > > > > > > On Sep 29, 2017, at 1:09 PM, Blake Eggleston <beggles...@apple.com> > > > wrote: > > > > > > > > Hi dev@, > > > > > > > > I’d like to propose that we retroactively classify materialized views > > as > > > an experimental feature, disable them by default, and require users to > > > enable them through a config setting before using. > > > > > > > > Materialized views have several issues that make them (effectively) > > > unusable in production. Some of the issues aren’t just implementation > > > problems, but problems with the design that aren’t easily fixed. It’s > > > unfair of us to make features available to users in this state without > > > providing a clear warning that bad or unexpected things are likely to > > > happen if they use it. > > > > > > > > Obviously, this isn’t great news for users that have already adopted > > > MVs, and I don’t have a great answer for that. I think that’s sort of a > > > sunk cost at this point. If they have any MV related problems, they’ll > > have > > > them whether they’re marked experimental or not. I would expect this to > > > reduce the number of users adopting MVs in the future though, and if > they > > > do, it would be opt-in. > > > > > > > > Once MVs reach a point where they’re usable in production, we can > > remove > > > the flag. Specifics of how the experimental flag would work can be > > hammered > > > out in a forthcoming JIRA, but I’d imagine it would just prevent users > > from > > > creating new MVs, and maybe log warnings on startup for existing MVs if > > the > > > flag isn’t enabled. > > > > > > > > Let me know what you think. > > > > > > > > Thanks, > > > > > > > > Blake > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > -- > > Ben Bromhead > > CTO | Instaclustr <https://www.instaclustr.com/> > > +1 650 284 9692 > > Reliability at Scale > > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer > > >
