>
> > This type of feature is very useful, but it may be easier to analyze
> this proposal if it’s compared with other DDM implementations from other
> databases? Would it be reasonable to add a table to the proposal comparing
> syntax and output from eg Azure SQL vs Cassandra vs whatever ?
Good
This type of feature is very useful, but it may be easier to analyze this
proposal if it’s compared with other DDM implementations from other databases?
Would it be reasonable to add a table to the proposal comparing syntax and
output from eg Azure SQL vs Cassandra vs whatever ?
> On Aug 19,
sounds interesting. I would like to understand a couple things here. If the
column names are the same for masked and unmasked data, it would impact
existing applications. I am curious what the transition plan look like for
applications that expect unmasked data?
For example, let’s say you
You mean entirely distinct CQL statements issued by the same client
“concurrently”?
If they’re submitted to the same coordinator then M2 will have a higher
timestamp than M1, so if M2 applies first then M1 will be a no-op and should
not generate any view update.
If submitted to different
Hi everyone,
I'd like to start a discussion about this proposal for dynamic data
masking:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
Dynamic data masking allows to obscure sensitive information without
changing the stored data. It would be based on a set
Perhaps my diagram was not clear. I am starting with mutations on the base
table. I assume they are not bundled together so from separate CQL
statements.
On Fri, Aug 19, 2022 at 11:11 AM Claude Warren, Jr
wrote:
> If each mutation comes from a separate CQL they would be separate, no?
>
>
> On
If each mutation comes from a separate CQL they would be separate, no?
On Fri, Aug 19, 2022 at 10:17 AM Benedict wrote:
> If M1 and M2 both operate over the same partition key they won’t be
> separate mutations, they should be combined into a single mutation before
> submission to SP.mutate
>
If M1 and M2 both operate over the same partition key they won’t be separate
mutations, they should be combined into a single mutation before submission to
SP.mutate
> On 19 Aug 2022, at 10:05, Claude Warren, Jr via dev
> wrote:
>
>
>
> # Table definitions
>
> Table [ Primary key ] other
# Table definitions
Table [ Primary key ] other data
base [ A B C ] D E
MV[ D C ] A B E
# Initial data
base -> MV
[ a b c ] d e -> [d c] a b e
[ a' b c ] d e -> [d c] a' b e
## Mutations -> expected outcome
M1: base [ a b c ] d e' -> MV [ d c ] a b e'
M2: base [ a b c ] d'
Since there seems to be agreement, I opened a ticket (CASSANDRA-17837) and
a pull request (https://github.com/apache/cassandra/pull/1799) in so that
the final text can be hashed out and accepted.
I also used the proposed pull request in the text of the pull so that it
can be seen in all its glory
10 matches
Mail list logo
