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

Reply via email to