Developers are also not the only people that are able to make decisions. Keeping it in the YAML means an operator can disable it vs a developer *maybe* seeing the warning. Keep in mind not everyone creates tables through CQLSH.
> On Oct 2, 2017, at 2:05 PM, Blake Eggleston <beggles...@apple.com> wrote: > > The message isn't materially different, but it will reach fewer people, > later. People typically aren't as attentive to logs as they should be. > Developers finding out about new warnings in the logs later than they could > have, sometimes even after it's been deployed, is not uncommon. It's happened > to me. Requiring a flag will reach everyone trying to use MVs as soon as they > start developing against MVs. Logging a warning will reach a subset of users > at some point, hopefully. The only downside I can think of for the flag is > that it's not as polite. > > On October 2, 2017 at 1:16:10 PM, 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
