It is different because it allows the operators to set those boundaries rather than rely on users doing the right thing.
So ideally you’d have the flag (and given the state of MVs, both design and the implementation, I’d argue the default should be NOPE) - for the operators, and a warning in cqlsh - for the developers. And no, we aren’t talking about throwing them out. But if we don’t manage to address its issues in a couple releases, then we should at least consider it eventually? At least https://issues.apache.org/jira/browse/CASSANDRA-10346 needs to be addressed IMO. — AY On 2 October 2017 at 21:16:17, Josh McKenzie (jmcken...@apache.org) wrote: "Nobody is talking about removing MVs." Not precisely true for this email thread: "but should there be some point in the future where we consider removing them from the code base unless they have gotten significant improvement as well?" IMO a .yaml change requirement isn't materially different than barfing a warning on someone's screen during the dev process when they use the DDL for MV's. At the end of the day, it's just a question of how forceful you want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT READY' in big bold letters, that's not going to miscommunicate to a user that 'feature X is ready' when it's not. Much like w/SASI, this is something that's in the code-base that for certain use-cases apparently works just fine. Might be worth considering the approach of making boundaries around those use-cases more rigid instead of throwing the baby out with the bathwater. On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan <doanduy...@gmail.com> wrote: > 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 > > > > >
