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
