Lot's of hard work by folks on MVs and I don't think this proposal is a commentary or reflection on that. What it is, is about signalling to users that this feature has more edge cases and caveats than other tried and true features (like all new features).
MVs are still a feature in a "stable" release and if it solves the end users problem but they are more aware of the edge cases because it is an explicit opt-in I think that would be quite beneficial. However this argument is more about user behaviour and guiding first time adopters so they have a better first time experience, which is a more nebulous concept with many approaches. The other side to proposal touches on the idea feature flags that operators can enable and disable depending on their organisational requirements and risk appetite. This is strongly related to the first point about guiding user behaviour, however it allows an organisation or operator to make that decision independent of their own end users. Whilst personally I would advocate for off by default for experimental / dangerous features (even retroactively doing it as suggested in the proposal), I do see the other side of the argument and we do need to give the quality control processes in place a chance to show fruit. I think the compromise suggested by Aleksey is fair. +1 to either A) or B) On Tue, 3 Oct 2017 at 09:29 Blake Eggleston <beggles...@apple.com> wrote: > The remaining issues are: > > * There's no way to determine if a view is out of sync with the base table. > * If you do determine that a view is out of sync, the only way to fix it > is to drop and rebuild the view. > * There are liveness issues with updates being reflected in the view. > > On October 3, 2017 at 9:00:32 AM, Sylvain Lebresne (sylv...@datastax.com) > wrote: > > On Tue, Oct 3, 2017 at 5:54 PM, Aleksey Yeshchenko <alek...@apple.com> > wrote: > > There are a couple compromise options here: > > > > a) Introduce the flag (enalbe_experimental_features, or maybe one per > experimental feature), set it to ‘false’ in the yaml, but have the default > be ‘true’. So that if you are upgrading from a previous minor to the next > without updating the yaml, you notice nothing. > > > > b) Introduce the flag in the minor, and set it to ‘true’ in the yaml in > 3.0 and 3.11, but to ‘false’ in 4.0. So the operators and in general people > who know better can still disable it with one flip, but nobody would be > affected by it in a minor otherwise. > > > > B might be more correct, and I’m okay with it > > Does feel more correct to me as well > > > although I do feel that we are behaving irresponsibly as developers by > allowing MV creation by default in their current state > > You're giving little credit to the hard work that people have put into > getting MV in a usable state. To quote Kurt's email: > > > And finally, back onto the original topic. I'm not convinced that MV's > need > > this treatment now. Zhao and Paulo (and others+reviewers) have made > quite a > > lot of fixes, granted there are still some outstanding bugs but the > > majority of bad ones have been fixed in 3.11.1 and 3.0.15, the remaining > > bugs mostly only affect views with a poor data model. Plus we've already > > required the known broken components require a flag to be turned on. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Reliability at Scale Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
