Thanks Carl & Jack, that explains it well. The servers does get busy when such
an update happens. Very helpful!
Will
Sent from my iPhone
> On 16 Dec 2015, at 00:05, Carl Yeksigian wrote:
>
> In the case of an update to the source table where data is changed, a
> tombstone will be generated f
It should all just work as expected, as if by magic. That's the whole point
of having MV, so that Cassandra does all the bookkeeping for you. Yes, the
partition key can change, so an update to the base table can cause one (or
more) MV rows to be deleted and one (or more) new MV rows to be created.
In the case of an update to the source table where data is changed, a
tombstone will be generated for the old value and an insert will be
generated for the new value. This happens serially for the source
partition, so if there are multiple updates to the same partition, a
tombstone will be generate
Haven't had a chance to yet but I will. However, trying might not fully explain
what happens behind the scenes, ie, you'd see the effect but not everything
that happens.
Thanks.
Sent from my iPhone
> On 15 Dec 2015, at 23:41, Laing, Michael wrote:
>
> why don't you just try it?
>
>> On Tu
why don't you just try it?
On Tue, Dec 15, 2015 at 6:30 PM, Will Zhang
wrote:
> Hi all,
>
> I originally raised this on SO, but not really getting any answer there,
> thought I give it a try here.
>
>
> Just thinking about this so please correct my understanding if any of this
> isn't right.
>
>
Hi all,
I originally raised this on SO, but not really getting any answer there,
thought I give it a try here.
Just thinking about this so please correct my understanding if any of this
isn't right.
Environment: Apache Cassandra v3.0.0
Say you have a table and a materialized view created on
