Ok so IF there is a flag to enable MV (à-la UDA/UDF in cassandra.yaml) then I'm fine with it. I initially understood that we wanted to disable it definitively. Maybe we should then add an explicit error message when MV is disabled and someone tries to use it, something like:
"MV has been disabled, to enable it, turn on the flag xxxx in cassandra.yaml" so users don't spend 3h searching around On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad <j...@jonhaddad.com> wrote: > 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 > >
