There’s a big difference between removal of a protocol that every single C* user had to use and disabling a feature which is objectively broken and almost nobody is using. Nobody is talking about removing MVs. If you want to use them you can enable them very trivially, but it should be an explicit option because they really aren’t ready for general use.
Claiming disabling by default == removal is not helpful to the conversation and is very misleading. Let’s be practical here. The people that are most likely to put MVs in production right now are people new to Cassandra that don’t know any better. The people that *should* be using MVs are the contributors to the project. People that actually wrote Cassandra code that can do a patch and push it into prod, and get it submitted upstream when they fix something. Yes, a lot of this stuff requires production usage to shake out the bugs, that’s fine, but we shouldn’t lie to people and say “feature X is ready” when it’s not. That’s a great way to get a reputation as “unstable” or “not fit for production." Jon > On Oct 2, 2017, at 11:54 AM, DuyHai Doan <doanduy...@gmail.com> wrote: > > "I would (in a patch release) disable MV CREATE statements, and emit > warnings for ALTER statements and on schema load if they’re not explicitly > enabled" > > --> I find this pretty extreme. Now we have an existing feature sitting > there in the base code but forbidden from version xxx onward. > > Since when do we start removing feature in a patch release ? (forbidding to > create new MV == removing the feature, defacto) > > Even the Thrift protocol has gone through a long process of deprecation and > will be removed on 4.0 > > And if we start opening the Pandora box like this, what's next ? Forbidding > to create SASI index too ? Removing Vnodes ? > > > > > On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan <jeremiah.jor...@gmail.com >> wrote: > >>> Only emitting a warning really reduces visibility where we need it: in >> the development process. >> >> How does emitting a native protocol warning reduce visibility during the >> development process? If you run CREATE MV and cqlsh then prints out a >> giant warning statement about how it is an experimental feature I think >> that is pretty visible during development? >> >> I guess I can see just blocking new ones without a flag set, but we need >> to be careful here. We need to make sure we don’t cause a problem for >> someone that is using them currently, even with all the edge cases issues >> they have now. >> >> -Jeremiah >> >> >>> On Oct 2, 2017, at 2:01 PM, Blake Eggleston <beggles...@apple.com> >> wrote: >>> >>> Yeah, I'm not proposing that we disable MVs in existing clusters. >>> >>> >>> On October 2, 2017 at 10:58:11 AM, Aleksey Yeshchenko (alek...@apple.com) >> wrote: >>> >>> The idea is to check the flag in CreateViewStatement, so creation of new >> MVs doesn’t succeed without that flag flipped. >>> >>> Obviously, just disabling existing MVs working in a minor would be silly. >>> >>> As for the warning - yes, that should also be emitted. Unconditionally. >>> >>> — >>> AY >>> >>> On 2 October 2017 at 18:18:52, Jeremiah D Jordan ( >> jeremiah.jor...@gmail.com) wrote: >>> >>> These things are live on clusters right now, and I would not want >> someone to upgrade their cluster to a new *patch* release and suddenly >> something that may have been working for them now does not function. >> Anyway, we need to be careful about how this gets put into practice if we >> are going to do it retroactively. >> >> >> --------------------------------------------------------------------- >> 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
