by
> CASSANDRA-13985 -
> https://github.com/apache/cassandra/commit/54de771e643e9cc64d1f5dd28b5de8a9a91a219e
> This will be firstly introduced in 4.0.
>
> Stefan
>
>> On Tue, 15 Dec 2020 at 13:49, Brian Hess wrote:
>>
>> One challenge to be aware of is that wh
One challenge to be aware of is that when you use multiple data centers, the
users can make changes in either data center and those changes will propagate
to the other data center. That is, there is no concept of a “read-only data
center” in Cassandra. That may be fine, but some organizations wa
Something folks haven't raised, but would be another impediment here is that in
Cassandra if you submit a batch (logged or unlogged) for two tables in the same
keyspace with the same partition then Cassandra collapses them into the same
Mutation and the two INSERTs are processed atomically. Ther
Jeremiah, this might be the exception, since the value that is being
aggregated is exactly the same value that determines liveliness of the
data, and more so since the aggregation requested is the *max* of the
timestamp, given that Cassandra is a Last-Write-Wins (so, looks at the
maximum timestamp)
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 bas
I have no vote here, but I think that #2 is not a good idea here. We would
be implicitly releasing an "odd" release with new features, which is more
than a little confusing. I do think that CDC is important, so I don't like
#4 (but for less important reasons than #2). So, I'm good with options 3
Not as of yet. See https://issues.apache.org/jira/browse/CASSANDRA-8234
Also, that use case is a lot like Materialized Views. See
https://issues.apache.org/jira/browse/CASSANDRA-6477
>Brian
Sent from my iPhone
> On May 20, 2015, at 1:23 AM, amit tewari wrote:
>
> Hi
>
> We would like to
wrote:
> Cassandra-jdbc can do cql3 as well as cql2. The rub (and why I would never
> recommend it) is that it does cql3 over thrift. So you lose out on all the
> native protocol features.
>
>
>
> > On May 11, 2015, at 2:53 PM, Brian Hess wrote:
> >
> > One thing that does j
One thing that does jump out at me, though, is about CQL2. As much as we
have advised against using cassandra-jdbc, I have encountered a few that
actually have used that as an integration point. I believe that
cassandra-jdbc is CQL2-based, which is the main reason we have been
advising folks agai
