> > So you’d rather continue to lie to users about the stability of the > feature rather than admitting it was merged in prematurely?
It was merged prematurely, but a lot has changed since then and a lot of fixes have been made, and now it's really no more awful than any other component of Cassandra. A lot of the commentary in here is coming from people who have had no part of the recent changes to MV's, and as 3.11.1 is not even out yet I doubt anyone really has any idea how stable they currently are. In fact I doubt many people have even operated or consulted on clusters with the most recent versions of 3.0 or 3.11. It's kind of really annoying that this has come up now, after we've already done a lot of the work to fix the known issues, and everyone seems to just be saying "they are so broken" but no one can really provide any evidence why. Ideally, we’d follow a process that looks a lot more like this: > 1. New feature is built with an opt in flag. Unknowns are documented, the > risk of using the feature is known to the end user. > 2. People test and use the feature that know what they’re doing. They are > able to read the code, submit patches, and help flush out the issues. They > do so in low risk environments. In the case of MVs, they can afford to > drop and rebuild the view over a week, or rebuild the cluster altogether. > We may not even need to worry as much about backwards compatibility. > 3. The feature matures. More tests are written. More people become aware > of how to contribute to the feature’s stability. > 4. After a while, we vote on removing the feature flag and declare it > stable for general usage. No I don't think this works very well for Cassandra because features are often heavily intertwined with other components of Cassandra, and often a new feature relies on making changes to other components of Cassandra. At least this is true for any feature that is large enough to justify having an opt-in flag. This will lead down the path of "oh it's only experimental/opt-in so we don't need to worry about testing every single component", which is wrong. We provide a database, and users expect stability from all aspects of the database, at all times. We should be working to fix bugs early so we can have confidence in the entire database from very early in the release branch. We shouldn't provide a database that people will say "don't use it in production until at least the .15 patch release". What I see is sufficient distrust coming from core committers, including > the author of the v1 design, to warrant opt-in for MVs. Core committers who have had almost nothing to do with MV since quite some time ago. Also I'm skeptical of how much first hand experience these core committers have with MV's. We already have those for UDFs and CDC. > We should have more: for triggers, SASI, and MVs, at least. Operators need > a way to disable features they haven’t validated. After a bit more thought I've changed my mind on this. Operators do need a way to disable features, but it makes a lot more sense to have that as part of the auth/roles system rather than yaml properties. Plus as previously noted, I'm not of the opinion we should release features (even in a beta/experimental form) at all, and we should be reasonably confident in the entire system and any new features being introduced prior to releasing them. We should also better practice incremental release of features, starting with a bare minimum, or subset of what we want the end product to be, rather than releasing a massive change and then calling it experimental for years until we can somehow deduce that it is stable enough. This could have been done for MV's by starting with an append only use case, and then moving onto the more complex transactional use case.
