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
