+1 to marking it experimental and also making it a prop to enable these features. By default I think they should be disabled.
On Fri, Sep 29, 2017 at 10:42 PM, Jeff Jirsa <jji...@gmail.com> wrote: > Reviewers should be able to suggest when experimental is warranted, and > conversation on dev+jira to justify when it’s transitioned from > experimental to stable? > > We should remove the flag as soon as we’re (collectively) confident in a > feature’s behavior - at least correctness, if not performance. > > > > On Sep 29, 2017, at 10:31 PM, Marcus Eriksson <krum...@gmail.com> wrote: > > > > +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 > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
