If a user (vs Cassandra dev) perspective is welcome - I'd recommend similarly identifying experimental features in the DESCRIBE / DESC cqlsh output as well.
On Mon, Oct 2, 2017 at 4:21 PM, Jeremiah D Jordan <jerem...@datastax.com> wrote: > Blake, > We are not saying to just put something in logs, we are talking about the > warn actually showing up in cqlsh. > When you issue a native protocol warn cqlsh will print it out on the > console in front of you in the results of the query. > https://issues.apache.org/jira/browse/CASSANDRA-8930 < > https://issues.apache.org/jira/browse/CASSANDRA-8930> > > For example for SASI it would look something like: > > > cqlsh:ks> CREATE CUSTOM INDEX ON sasi_table (c) USING > 'org.apache.cassandra.index.sasi.SASIIndex'; > > Warnings : > A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental, > take extra caution when using it in production. > > cqlsh:ks> > > -Jeremiah > > > On Oct 2, 2017, at 5: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 > >>> > >>> > >> > >
