> 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
