Lots of users are already using MV's, believe it or not in some cases quite effectively and also on older versions which were still exposed to a lot of the bugs that cause inconsistencies. 3.11.1 has come a long way since then and I think with a bit more documentation around the current issues marking MV's as experimental is unnecessary and likely annoying for current users. On that note we've already had complaints about changing defaults and behaviours willy nilly across majors and minors, I can't see this helping our cause. Sure, you can make it "seamless" from an upgrade perspective, but that doesn't account for every single way operators do things. I'm sure someone will express surprise when they run up a new cluster or datacenter for testing with default config and find out that they have to enable MV's. Meanwhile they've been using them the whole time and haven't had any major issues because they didn't touch the edge cases.
I'd like to point out that introducing "experimental" features sets a precedent for future releases, and will likely result in using the "experimental" tag to push out features that are not ready (again). In fact we already routinely say >=3 isn't production ready yet, so why don't we just mark 3+ as "experimental" as well? I don't think experimental is the right approach for a database. The better solution, as I said, is more verification and testing during the release process (by users!). A lot of other projects take this approach, and it certainly makes sense. It could also be coupled with beta releases, so people can start getting verification of their new features at an earlier date. Granted this is similar to experimental features, but applied to the whole release rather than just individual features. * There's no way to determine if a view is out of sync with the base table. > As already pointed out by Jake, this is still true when you don't use MV's. We should document this. I think it's entirely fair to say that users *should not *expect this to be done for them. There is also no way for a user to determine they have inconsistencies short of their own verification. And also a lot of the synchronisation problems have been resolved, undoubtedly there are more unknowns out there but what MV's have is still better than managing your own. > * If you do determine that a view is out of sync, the only way to fix it > is to drop and rebuild the view. > This is undoubtedly a problem, but also no worse than managing your own views. Also at least there is still a way to fix your view. It certainly shouldn't be as common in 3.11.1/3.0.15, and we have enough insight now to be able to tell when out of sync will actually occur, so we can document those cases. > * There are liveness issues with updates being reflected in the view. What specific issues are you referring to here? The only one I'm aware of is deletion of unselected columns in the view affecting out of order updates. If we deem this a major problem we can document it or at least put a restriction in place until it's fixed in CASSANDRA-13826 <https://issues.apache.org/jira/browse/CASSANDRA-13826> In this case, 'out of sync' means 'you lost data', since the current design > + repair should keep things eventually consistent right? I'd like Zhao or Paulo to confirm here but I believe the only way you can really "lose data" (that can't be repaired) here would be partition deletions on massively wide rows in the view that will not fit in the batchlog (256mb/max value size) as it currently stands. Frankly this is probably an anti-pattern for MV's at the moment anyway and one we should advise against.
