Okies now I understand what you mean by "same" partition key. I think you are saying
PRIMARY KEY(col1, col2, col3) == PRIMARY KEY(col2, col1, col3) // so far I assumed they are different partition keys. On Fri, Feb 10, 2017 at 10:36 AM, Benjamin Roth <benjamin.r...@jaumo.com> wrote: > There are use cases where the partition key is the same. For example if you > need a sorting within a partition or a filtering different from the > original clustering keys. > We actually use this for some MVs. > > If you want "dumb" denormalization with simple append only cases (or more > general cases that don't require a read before write on update) you are > maybe better off with batched denormalized atomics writes. > > The main benefit of MVs is if you need denormalization to sort or filter by > a non-primary key field. > > 2017-02-10 19:31 GMT+01:00 Kant Kodali <k...@peernova.com>: > > > yes thanks for the clarification. But why would I ever have MV with the > > same partition key? if it is the same partition key I could just read > from > > the base table right? our MV Partition key contains the columns from the > > base table partition key but in a different order plus an additional > column > > (which is allowed as of today) > > > > On Fri, Feb 10, 2017 at 10:23 AM, Benjamin Roth <benjamin.r...@jaumo.com > > > > wrote: > > > > > It depends on your model. > > > If the base table + MV have the same partition key, then the MV > mutations > > > are applied synchronously, so they are written as soon the write > request > > > returns. > > > => In this case you can rely on the R+F > RF > > > > > > If the partition key of the MV is different, the partition of the MV is > > > probably placed on a different host (or said differently it cannot be > > > guaranteed that it is on the same host). In this case, the MV updates > are > > > executed async in a logged batch. So it can be guaranteed they will be > > > applied eventually but not at the time the write request returns. > > > => You cannot rely and there is no possibility to absolutely guarantee > > > anything, not matter what CL you choose. A MV update may always "arrive > > > late". I guess it has been implemented like this to not block in case > of > > > remote request to prefer the cluster sanity over consistency. > > > > > > Is it now 100% clear? > > > > > > 2017-02-10 19:17 GMT+01:00 Kant Kodali <k...@peernova.com>: > > > > > > > So R+W > RF doesnt apply for reads on MV right because say I set > QUORUM > > > > level consistency for both reads and writes then there can be a > > scenario > > > > where a write is successful to the base table and then say > immediately > > I > > > do > > > > a read through MV but prior to MV getting the update from the base > > table. > > > > so there isn't any way to make sure to read after MV had been > > > successfully > > > > updated. is that correct? > > > > > > > > On Fri, Feb 10, 2017 at 6:30 AM, Benjamin Roth < > > benjamin.r...@jaumo.com> > > > > wrote: > > > > > > > > > Hi Kant > > > > > > > > > > Is it clear now? > > > > > Sorry for the confusion! > > > > > > > > > > Have a nice one > > > > > > > > > > Am 10.02.2017 09:17 schrieb "Kant Kodali" <k...@peernova.com>: > > > > > > > > > > thanks! > > > > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth < > > benjamin.r...@jaumo.com > > > > > > > > > wrote: > > > > > > > > > > > Yes it is > > > > > > > > > > > > Am 10.02.2017 00:46 schrieb "Kant Kodali" <k...@peernova.com>: > > > > > > > > > > > > > If reading from materialized view with a consistency level of > > > quorum > > > > am > > > > > I > > > > > > > guaranteed to have the most recent view? other words is w + r > > n > > > > > > contract > > > > > > > maintained for MV's as well for both reads and writes? > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Benjamin Roth > > > Prokurist > > > > > > Jaumo GmbH · www.jaumo.com > > > Wehrstraße 46 · 73035 Göppingen · Germany > > > Phone +49 7161 304880-6 · Fax +49 7161 304880-1 > > > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer > > > > > > > > > -- > Benjamin Roth > Prokurist > > Jaumo GmbH · www.jaumo.com > Wehrstraße 46 · 73035 Göppingen · Germany > Phone +49 7161 304880-6 · Fax +49 7161 304880-1 > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer >
