To clarify: > > * 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.
In this case, 'out of sync' means 'you lost data', since the current design + repair should keep things eventually consistent right? Not saying that's ideal, and not saying having no visibility to holes like that from data loss is acceptable either, just trying to make sure we're all on the same page here. On Tue, Oct 3, 2017 at 3:09 PM, Jeff Jirsa <jji...@gmail.com> wrote: > Nobody debates that it's easier, the debate is over whether or not it's > correct (and more importantly, whether or not people realize it's not > strictly correct in all edge cases). > > Users expect correct results. People are literally betting their jobs on > it. When you have to manually manage sync between two tables, you at least > become (painfully) aware that correctness is difficult and you can't count > on it (maybe you need an app level re-sync or similar). > > When you use a feature that is built in, people will assume it's correct, > and there's no way for the average user to know that's not the case right > now. > > Put another way: > > If your bank decided to use MVs right now for your personal bank/investment > accounts, would you be ok with that? > If not, then we need a way to stop the banks (and all other cassandra > users) from doing it without realizing that it's not OK. > > > > > On Tue, Oct 3, 2017 at 12:02 PM, Jake Luciani <jak...@gmail.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. > > > > > > > I just want to mention that manual de-normalization has all the same > issues > > as the list of above. If you write to multiple tables with batch logs > when > > do you know the data is consistent? > > In fact, manual de-normalization is worse because you can't manually > handle > > updates to existing data due to the lack of synchronization on read > before > > write. > > > > I think a lot of you have lost sight on what MV was intended for, as a > way > > to keep developers from manually maintaining a consistent view of data > > across tables. > > There is still the fundamental problem of managing multiple views of data > > even if you remove the MV feature, you just make it someone else's > problem. > > > > I'll re-post this blog from back when MVs first came out to hopefully > clear > > questions up on the goals of MV. > > > > https://www.datastax.com/dev/blog/understanding-materialized-views > > > > -Jake > > > > > > On Tue, Oct 3, 2017 at 2:50 PM, Aleksey Yeshchenko <alek...@apple.com> > > wrote: > > > > > Indeed. Paulo and Zhao did a lot of good work to make the situation > less > > > bad. You did some as well. Even I retouched small parts of it - > metadata > > > related. I’m sorry if I came off as disrespectful - I didn’t mean to. > > I’ve > > > seen and I appreciate every commit that went into it. > > > > > > It is however my opinion that we started at a very low point, for a > > > variety of reasons, and climbing out of that initial poor state, to the > > > level that power users start having trust in MVs and overcome the > initial > > > deservedly poor impression, will probably take even more work. And > > when/if > > > we get there, maybe we won’t need the switch anymore. > > > > > > — > > > AY > > > > > > On 3 October 2017 at 17:00:31, Sylvain Lebresne (sylv...@datastax.com) > > > wrote: > > > > > > You're giving little credit to the hard work that people have put into > > > getting MV in a usable state. > > > > > > > > > > > -- > > http://twitter.com/tjake > > >
