"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 > >
