Yes, I understand what you're saying. The points I'm making about logs still apply. It's possible for drivers and object mappers to handle queries and schema changes, and have developers rarely open cqlsh. It's also not uncommon for schema changes to be done by a different group than the developers writing the application.
On October 2, 2017 at 2:21:38 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 >>> >>> >>
