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