Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

In that case I can't even say same partition key == same row key The below would be different partition keys according to you right? PRIMARY KEY ((a, b), c, d) and PRIMARY KEY ((a, b), d, c, e) On Fri, Feb 10, 2017 at 10:48 AM, Benjamin Roth wrote: > Same partition

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

Thanks a lot for that post. If I read the code right, then there is one case missing in your post. According to StorageProxy.mutateMV, local updates are NOT put into a batch and are instantly applied locally. So a batch is only created if remote mutations have to be applied and only for those

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

See my blog post to understand how MV is implemented: http://www.doanduyhai.com/blog/?p=1930 On Fri, Feb 10, 2017 at 7:48 PM, Benjamin Roth wrote: > Same partition key: > > PRIMARY KEY ((a, b), c, d) and > PRIMARY KEY ((a, b), d, c) > > PRIMARY KEY ((a), b, c) and >

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

On Fri, Feb 10, 2017 at 1:13 PM, Benjamin Roth wrote: > Thanks a lot for that post. If I read the code right, then there is one > case missing in your post. > According to StorageProxy.mutateMV, local updates are NOT put into a batch > and are instantly applied locally.

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

PRIMARY KEY ( (Partition key), Clustering Keys) : On Fri, Feb 10, 2017 at 10:59 AM DuyHai Doan wrote: > See my blog post to understand how MV is implemented: > http://www.doanduyhai.com/blog/?p=1930 > > On Fri, Feb 10, 2017 at 7:48 PM, Benjamin Roth

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

No your example has different PRIMARY keys but same PARTITION keys. Same partition keys generate same token and will always go to the same host. 2017-02-10 19:58 GMT+01:00 Kant Kodali : > In that case I can't even say same partition key == same row key > > The below would be

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

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 wrote: > There

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

@Benjamin Roth: How do you say something is a different PRIMARY KEY now? looks like you are saying The below is same partition key and same primary key? PRIMARY KEY ((a, b), c, d) and PRIMARY KEY ((a, b), d, c) @Russell Great to see you here! As always that is spot on! On Fri, Feb 10, 2017 at

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

Same partition key: PRIMARY KEY ((a, b), c, d) and PRIMARY KEY ((a, b), d, c) PRIMARY KEY ((a), b, c) and PRIMARY KEY ((a), c, b) Different partition key: PRIMARY KEY ((a, b), c, d) and PRIMARY KEY ((a), b, d, c) PRIMARY KEY ((a), b) and PRIMARY KEY ((b), a) 2017-02-10 19:46 GMT+01:00 Kant

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

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

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

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

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

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

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

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

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

thanks! On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth wrote: > Yes it is > > Am 10.02.2017 00:46 schrieb "Kant Kodali" : > > > If reading from materialized view with a consistency level of quorum am I > > guaranteed to have the most recent view? other

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

This is not true. You cannot provide a ConsistencyLevel for the Materialized Views on a table when you do a write. That is, you do not explicitly write to a Materialized View, but implicitly write to it via the base table. There is not consistency guarantee other than eventual between the

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

Basically MV updates are processed when a mutation is applied. For MV replicas that stay local, MV mutations are also applied directly (see StorageProxy.mutateMV). For remote MV mutations, a batch is created. Maybe I am wrong but code is somehow contradictory: TableView.pushViewReplicaUpdates:

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

I agree with Brian. As far as I am concerned an update of materialized view is an async operation. Therefore I don't believe that you'd get most up to date data. Salih Gedik > On 10 Feb 2017, at 16:11, Brian Hess wrote: > > This is not true. > > You cannot provide a

Re: Have a CDC commitLog process option in Cassandra

The primary reason I avoided integrating a daemon into the Cassandra process was the increase in heap pressure and further muddying of the profile of heap usage. We've already seen that mixing read/write, compaction, streaming, and repair in the same JVM causes a nasty mix of allocation patterns

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

See my latest comment 2017-02-10 14:33 GMT+01:00 Salih Gedik : > I agree with Brian. As far as I am concerned an update of materialized > view is an async operation. Therefore I don't believe that you'd get most > up to date data. > > Salih Gedik > > > > On 10 Feb 2017, at 16:11,

Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?

Hi Kant Is it clear now? Sorry for the confusion! Have a nice one Am 10.02.2017 09:17 schrieb "Kant Kodali" : thanks! On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth wrote: > Yes it is > > Am 10.02.2017 00:46 schrieb "Kant Kodali"