Having now helped a few folks that have put MVs into prod without realizing what they got themselves into, I’m +1 on a flag disabling the feature by default. A WARN message would not have helped them.
> On Oct 2, 2017, at 10:56 AM, Blake Eggleston <beggles...@apple.com> wrote: > > Yeah I’m not sure that just emitting a warning is enough. The point is to be > super explicit that bad things will happen if you use MVs. 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. Only > emitting a warning really reduces visibility where we need it: in the > development process. > > By only emitting warning, we're just protecting users that don't run even > rudimentary tests before upgrading their clusters. If an operator is going to > blindly deploy a database update to prod without testing, they’re going to > poke their eye out on something anyway. Whether it’s an MV flag or something > else. If we make this change clear in NEWS.txt, and the user@ list, I think > that’s the best thing to do. > > > On October 2, 2017 at 10:18:52 AM, Jeremiah D Jordan > (jeremiah.jor...@gmail.com) wrote: > > Hindsight is 20/20. For 8099 this is the reason we cut the 2.2 release before > 8099 got merged. > > But moving forward with where we are now, if we are going to start adding > some experimental flags to things, then I would definitely put SASI on this > list as well. > > For both SASI and MV I don’t know that adding a flags in the cassandra.yaml > which prevents their use is the right way to go. I would propose that we emit > WARN from the native protocol mechanism when a user does an ALTER/CREATE what > ever that tries to use an experiment feature, and probably in the system.log > as well. So someone who is starting new development using them will get a > warning showing up in cqlsh “hey the thing you just used is experimental, > proceed with caution” and also in their logs. > > 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. > > -Jeremiah > > >> On Oct 1, 2017, at 5:36 PM, Josh McKenzie <jmcken...@apache.org> wrote: >> >>> >>> I think committing 8099, or at the very least, parts of it, behind an >>> experimental flag would have been the right thing to do. >> >> With a major refactor like that, it's a staggering amount of extra work to >> have a parallel re-write of core components of a storage engine accessible >> in parallel to the major based on an experimental flag in the same branch. >> I think the complexity in the code-base of having two such channels in >> parallel would be an altogether different kind of burden along with making >> the work take considerably longer. The argument of modularizing a change >> like that, however, is something I can get behind as a matter of general >> principle. As we discussed at NGCC, the amount of static state in the C* >> code-base makes this an aspirational goal rather than a reality all too >> often, unfortunately. >> >> Not looking to get into the discussion of the appropriateness of 8099 and >> other major refactors like it (nio MessagingService for instance) - but >> there's a difference between building out new features and shielding the >> code-base and users from their complexity and reliability and refactoring >> core components of the code-base to keep it relevant. >> >> On Sun, Oct 1, 2017 at 5:01 PM, Dave Brosius <dbros...@apache.org> wrote: >> >>> triggers >>> >>> >>> On 10/01/2017 11:25 AM, Jeff Jirsa wrote: >>> >>>> Historical examples are anything that you wouldn’t bet your job on for >>>> the first release: >>>> >>>> Udf/uda in 2.2 >>>> Incremental repair - would have yanked the flag following 9143 >>>> SASI - probably still experimental >>>> Counters - all sorts of correctness issues originally, no longer true >>>> since the rewrite in 2.1 >>>> Vnodes - or at least shuffle >>>> CDC - is the API going to change or is it good as-is? >>>> CQL - we’re on v3, what’s that say about v1? >>>> >>>> Basically anything where we can’t definitively say “this feature is going >>>> to work for you, build your product on it” because companies around the >>>> world are trying to make that determination on their own, and they don’t >>>> have the same insight that the active committers have. >>>> >>>> The transition out we could define as a fixed number of releases or a dev@ >>>> >>>> vote, I don’t think you’ll find something that applies to all experimental >>>> >>>> features, so being flexible is probably the best bet there >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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
