At the risk of sounding redundant it sounds like for MVs at this point we want to preserve current functionality for existing users. We would have a flag in the yaml to disable it by default for new MV creation with an error message. In addition we want a warning in the log and in cqlsh upon creation and usage even with it enabled. We could be very explicit with a message to the user list and a clear NEWS item and upgrade note.
For SASI, it seems like a similar pattern could be used. For either or both of these features, a Jira epic could be created to make a path to making it a full-fledged non-experimental feature. That could include a ticket for realistic testing within the boundaries of the target use cases - that way people can point to what testing has been done and what the target use cases were. An epic and test ticket would give people a pathway to make it no longer experimental so it isn’t lingering halfway in the codebase indefinitely and for interested parties something to contribute towards. Granted if issues are found, they’d need to be added to the epic. >> On Oct 2, 2017, at 6:16 PM, Mick Semb Wever <m...@thelastpickle.com> wrote: >> >> On 3 October 2017 at 04:57, Aleksey Yeshchenko <alek...@apple.com> wrote: >> >> The idea is to check the flag in CreateViewStatement, so creation of new >> MVs doesn’t succeed without that flag flipped. >> Obviously, just disabling existing MVs working in a minor would be silly. >> As for the warning - yes, that should also be emitted. Unconditionally. > > > Thanks Aleksey, this was the best read in this thread imo of what should be > done with MVs. > (With these warnings being emitted in both logs and cqlsh). > > Hopefully similar "creation flags" and log+cqlsh warnings can be added to: > triggers, SASI, and incremental repair (<4.0). > > CDC sounds like it is in the same basket, but it already has the > `cdc_enabled` yaml flag which defaults false. > > Mick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
