[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-dev
Subject:    Re: Proposal to retroactively mark materialized views experimental
From:       sankalp kohli <kohlisankalp () gmail ! com>
Date:       2017-09-30 6:09:45
Message-ID: CAEPxca0RGZ6zRbGHu-tJE0mv3D-hs0A0EKQe1SvpVt6WP9Srgw () mail ! gmail ! com
[Download RAW message or body]


+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 <jjirsa@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 <krummas@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
> <vchella@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 <ben@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 <jon@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 <beggleston@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-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>


[prev in list] [next in list] [prev in thread] [next in thread]