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

[Edward Capriolo]

On Sat, Feb 11, 2017 at 3:03 AM, Benjamin Roth 
wrote:

> For MVs regarding this threads question only the partition key matters.
> Different primary keys can have the same partition key. Which is the case
> in the example in your last comment.
>
> Am 10.02.2017 20:26 schrieb "Kant Kodali" :
>
> @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 11:13 AM, 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. So a batch is only created if remote
> > mutations have to be applied and only for those mutations.
> >
> > 2017-02-10 19:58 GMT+01:00 DuyHai Doan :
> >
> > > 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 <
> benjamin.r...@jaumo.com>
> > > wrote:
> > >
> > > > 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 Kodali :
> > > >
> > > > > 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 :
> > > > > >
> > > > > > > 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 

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

[Edward Capriolo]

If you want to test the scenarios thia project would be helpful
Http://github.com/edwardcapriolo/ec

I use brute force at different CL and assert if i detect and consistency
issues. Having mvs would be nice


On Saturday, February 11, 2017, Benjamin Roth 
wrote:

> For MVs regarding this threads question only the partition key matters.
> Different primary keys can have the same partition key. Which is the case
> in the example in your last comment.
>
> Am 10.02.2017 20:26 schrieb "Kant Kodali"  >:
>
> @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 11:13 AM, 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. So a batch is only created if remote
> > mutations have to be applied and only for those mutations.
> >
> > 2017-02-10 19:58 GMT+01:00 DuyHai Doan  >:
> >
> > > 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 <
> benjamin.r...@jaumo.com >
> > > wrote:
> > >
> > > > 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 Kodali  >:
> > > >
> > > > > 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  >:
> > > > > >
> > > > > > > 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 

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

[Benjamin Roth]

For MVs regarding this threads question only the partition key matters.
Different primary keys can have the same partition key. Which is the case
in the example in your last comment.

Am 10.02.2017 20:26 schrieb "Kant Kodali" :

@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 11:13 AM, 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. So a batch is only created if remote
> mutations have to be applied and only for those mutations.
>
> 2017-02-10 19:58 GMT+01:00 DuyHai Doan :
>
> > 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
> > > 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 Kodali :
> > >
> > > > 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 :
> > > > >
> > > > > > 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 :
> > > > > > >
> > > > > > > > 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
> > > 

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

[Kant Kodali]

@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 11:13 AM, 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. So a batch is only created if remote
> mutations have to be applied and only for those mutations.
>
> 2017-02-10 19:58 GMT+01:00 DuyHai Doan :
>
> > 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
> > > 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 Kodali :
> > >
> > > > 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 :
> > > > >
> > > > > > 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 :
> > > > > > >
> > > > > > > > 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
> > > > > > > > 

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

[Tyler Hobbs]

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. So a batch is only created if remote
> mutations have to be applied and only for those mutations.
>

I can confirm that your understanding is correct here.  If the "paired" MV
replica happens to be the same node (which is guaranteed if and only if the
partition key is the same), the mutation is immediately applied locally.


-- 
Tyler Hobbs
DataStax 

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

[Benjamin Roth]

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 mutations.

2017-02-10 19:58 GMT+01:00 DuyHai Doan :

> 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
> > 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 Kodali :
> >
> > > 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 :
> > > >
> > > > > 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 :
> > > > > >
> > > > > > > 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"  >:
> > > > > > > >
> > > > > > > > thanks!
> > > > > > > >
> > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth <
> > > > > benjamin.r...@jaumo.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > 

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

[Benjamin Roth]

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 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 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 Kodali :
> >
> > > 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 :
> > > >
> > > > > 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 :
> > > > > >
> > > > > > > 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"  >:
> > > > > > > >
> > > > > > > > thanks!
> > > > > > > >
> > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth <
> > > > > benjamin.r...@jaumo.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Yes it is
> > > > > > > > >
> > > > > > > 

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

[Russell Spitzer]

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 
> wrote:
>
> > 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 Kodali :
> >
> > > 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 :
> > > >
> > > > > 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 :
> > > > > >
> > > > > > > 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"  >:
> > > > > > > >
> > > > > > > > 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
> > > > 

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

[Kant Kodali]

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 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 Kodali :
>
> > 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 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 :
> > >
> > > > 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 :
> > > > >
> > > > > > 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" :
> > > > > > >
> > > > > > > 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"  >:
> > > > > > > >
> > > > > > > > > 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!
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > 

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

[DuyHai Doan]

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
> 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 Kodali :
>
> > 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 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 :
> > >
> > > > 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 :
> > > > >
> > > > > > 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" :
> > > > > > >
> > > > > > > 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"  >:
> > > > > > > >
> > > > > > > > > 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
> > > > >
> > > > > 

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

[Benjamin Roth]

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 Kodali :

> 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 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 :
> >
> > > 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 :
> > > >
> > > > > 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" :
> > > > > >
> > > > > > 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" :
> > > > > > >
> > > > > > > > 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
> >
>



-- 
Benjamin Roth
Prokurist

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

[Kant Kodali]

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 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 :
>
> > 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  >
> > 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 :
> > >
> > > > 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" :
> > > > >
> > > > > 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" :
> > > > > >
> > > > > > > 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
>

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

[Benjamin Roth]

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 :

> 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 
> 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 :
> >
> > > 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" :
> > > >
> > > > 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" :
> > > > >
> > > > > > 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

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

[Kant Kodali]

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

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

[Benjamin Roth]

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 :

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

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

[Kant Kodali]

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

> 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" :
> >
> > > 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!
> > >
> >
>

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

[Benjamin Roth]

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" :
>
> > 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!
> >
>

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

[Benjamin Roth]

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, Brian Hess  wrote:
> >
> > 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 base table and
> the Materialized View. That is, the coordinator only acknowledges the write
> when the proper number of replicas in the base table have acknowledged
> successful writing. There is no waiting or acknowledgement for any
> Materialized Views on that table.
> >
> > Therefore, while you can specify a Consistency Level on read since you
> are reading directly from the Materialized View as a table, you cannot
> specify a Consistency Level on wrote for the Materialized View. So, you
> cannot apply the R+W>RF formula.
> >
> > >Brian
> >
> >> On Feb 10, 2017, at 3:17 AM, Kant Kodali  wrote:
> >>
> >> 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 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

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

[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, Brian Hess  wrote:
> 
> 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 base table and the Materialized 
> View. That is, the coordinator only acknowledges the write when the proper 
> number of replicas in the base table have acknowledged successful writing. 
> There is no waiting or acknowledgement for any Materialized Views on that 
> table. 
> 
> Therefore, while you can specify a Consistency Level on read since you are 
> reading directly from the Materialized View as a table, you cannot specify a 
> Consistency Level on wrote for the Materialized View. So, you cannot apply 
> the R+W>RF formula. 
> 
> >Brian
> 
>> On Feb 10, 2017, at 3:17 AM, Kant Kodali  wrote:
>> 
>> 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 words is w + r > n
>>> contract
 maintained for MV's as well for both reads and writes?
 
 Thanks!
>>> 

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

[Benjamin Roth]

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:

// now actually perform the writes and wait for them to complete
> asyncWriteBatchedMutations(wrappers, localDataCenter, Stage.VIEW_MUTATION);


Comment says, caller waits for updates, but code executes async. So you are
right in the case MV has a different PK than base table and replica goes to
a remote host. If base PK == mv PK then updates are always local and sync.

Did I still miss sth?

2017-02-10 14:11 GMT+01:00 Brian Hess :

> 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 base table and
> the Materialized View. That is, the coordinator only acknowledges the write
> when the proper number of replicas in the base table have acknowledged
> successful writing. There is no waiting or acknowledgement for any
> Materialized Views on that table.
>
> Therefore, while you can specify a Consistency Level on read since you are
> reading directly from the Materialized View as a table, you cannot specify
> a Consistency Level on wrote for the Materialized View. So, you cannot
> apply the R+W>RF formula.
>
> >Brian
>
> > On Feb 10, 2017, at 3:17 AM, Kant Kodali  wrote:
> >
> > 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 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

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

[Brian Hess]

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 base table and the Materialized 
View. That is, the coordinator only acknowledges the write when the proper 
number of replicas in the base table have acknowledged successful writing. 
There is no waiting or acknowledgement for any Materialized Views on that 
table. 

Therefore, while you can specify a Consistency Level on read since you are 
reading directly from the Materialized View as a table, you cannot specify a 
Consistency Level on wrote for the Materialized View. So, you cannot apply the 
R+W>RF formula. 

>Brian

> On Feb 10, 2017, at 3:17 AM, Kant Kodali  wrote:
> 
> 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 words is w + r > n
>> contract
>>> maintained for MV's as well for both reads and writes?
>>> 
>>> Thanks!
>>> 
>> 

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

[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" :
>
> > 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!
> >
>

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

[Benjamin Roth]

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 words is w + r > n contract
> maintained for MV's as well for both reads and writes?
>
> Thanks!
>

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

[Kant Kodali]

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!