Re: [VOTE] CEP-20: Dynamic Data Masking

[Mick Semb Wever]

>
> I'd like to propose CEP-20 for approval.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
> Discussion:
> https://lists.apache.org/thread/qsmxsymozymy6dy9tp5xw9gn5fhz9nt4
>
> The vote will be open for 72 hours.
> Votes by committers are considered binding.
> A vote passes if there are at least three binding +1s and no binding
> vetoes.
>



+1

Re: CEP-15 multi key transaction syntax

[Caleb Rackliffe]

Yeah, if you remember Blake's original syntax proposal, the IF condition
was actually specified outside the body of the transaction following the
COMMIT TRANSACTION phrase. (i.e. COMMIT TRANSACTION IF blah, blah)

The current syntax only changed that superficially, but in doing so, it
left the door open structurally for an arbitrary number of conditional and
unconditional updates.

I've got a large TODO list already to get this ready to review ASAP, but
I'll noodle on it and we can make a final decision when that gets closer. I
also lean toward doing it when "we support arbitrary numbers of IF
statements".

On Wed, Sep 21, 2022 at 3:41 PM David Capwell  wrote:

> I expect that a lot of use cases will update M and insert into N tables
> based on one condition
>
>
> Jeff, the issue is a scope issue
>
> — works fine today
> IF …
>   UPDATE ….;
>   INSERT …;
> END IF
>
> — also works today just fine; no condition is used with the mutations
> UPDATE ….;
> INSERT …;
>
> — does not work today
> IF
>   UPDATE ….;
>   INSERT …;
> END IF
> — this breaks the parser as it does not belong to the above IF block
> INSERT …;
>
> So its not that updating multiple tables is a problem, its just that
> mapping mutations to conditions is purely on if a condition exists today
> and the parser assumes this as well… so all mutations are tied to a
> condition if present, else all mutations have no conditions…. The parser
> helps enforce this by failing if you mix.
>
> My inclination is not to support this until we support arbitrary numbers
> of IF statements.
>
>
> That is my feeling as well.  I am cool with v1 having this limitation as
> it does NOT block future versions to enhance the syntax, and when we can
> support multiple IF then we need to decouple this current implementation
> detail… so easier to deal with then.
>
> On Sep 21, 2022, at 1:22 PM, Benedict  wrote:
>
> Not quite sure I follow, but the syntax we agreed permits you to update as
> many tables as you like with a single condition, or with no condition, but
> not to mix both conditional and unconditional updates in a single
> transaction.
>
> My preference is to keep this simple until we permit arbitrarily complex
> logic, ie sequences of (potentially nested) ifs and unconditional updates.
>
> On 21 Sep 2022, at 21:04, Jeff Jirsa  wrote:
>
> 
> I expect that a lot of use cases will update M and insert into N tables
> based on one condition, so if that's a problem with the grammar today, I
> think it'd probably be worth the time to sort that out?
>
>
>
> On Wed, Sep 21, 2022 at 12:42 PM David Capwell  wrote:
>
>> Caleb is making great progress on this, and I have been working on CQL
>> fuzz testing the new grammar to make sure we flesh out cases quickly; one
>> thing we hit was about mixing conditional and non-conditional updates; will
>> use a example to better show
>>
>> BEGIN TRANSACTION
>>   LET a = (SELECT * FROM ….);
>>   IF a IS NOT NULL THEN
>> UPDATE …;
>>   END IF
>>   INSERT INTO ...
>> COMMIT TRANSACTION
>>
>> In this case we have 1 UPDATE tied to the IF condition, and one INSERT
>> that isn’t… for v1 do we need/want to support this, or is it best for v1 to
>> be simple and have all updates tied to conditional when present?
>>
>> On Aug 22, 2022, at 9:19 AM, Avi Kivity via dev 
>> wrote:
>>
>> I wasn't referring to specific syntax but to the concept. If a SQL
>> dialect (or better, the standard) has a way to select data into a variable,
>> let's adopt it.
>>
>> If such syntax doesn't exist, LET (a, b, c) = (SELECT x, y, z FROM tab)
>> is my preference.
>>
>> On 8/22/22 19:13, Patrick McFadin wrote:
>>
>> The replies got trashed pretty badly in the responses.
>> When you say: "Agree it's better to reuse existing syntax than invent new
>> syntax."
>>
>> Which syntax are you referring to?
>>
>> Patrick
>>
>>
>> On Mon, Aug 22, 2022 at 1:36 AM Avi Kivity via dev <
>> dev@cassandra.apache.org> wrote:
>>
>>> Agree it's better to reuse existing syntax than invent new syntax.
>>>
>>> On 8/21/22 16:52, Konstantin Osipov wrote:
>>> > * Avi Kivity via dev  [22/08/14 15:59]:
>>> >
>>> > MySQL supports SELECT  INTO  FROM ... WHERE
>>> > ...
>>> >
>>> > PostgreSQL supports pretty much the same syntax.
>>> >
>>> > Maybe instead of LET use the ANSI/MySQL/PostgreSQL DECLARE var TYPE and
>>> > MySQL/PostgreSQL SELECT ... INTO?
>>> >
>>> >> On 14/08/2022 01.29, Benedict Elliott Smith wrote:
>>> >>> 
>>> >>> I’ll do my best to express with my thinking, as well as how I would
>>> >>> explain the feature to a user.
>>> >>>
>>> >>> My mental model for LET statements is that they are simply SELECT
>>> >>> statements where the columns that are selected become variables
>>> >>> accessible anywhere in the scope of the transaction. That is to say,
>>> you
>>> >>> should be able to run something like s/LET/SELECT and
>>> >>> s/([^=]+)=([^,]+)(,|$)/\2 AS \1\3/g on the columns of a LET statement
>>> >>> and produce a valid SELECT statement, and vice versa. Both should
>>> >>> p

Checkstyle will be updated to fail Ant build when unused imports are present in the code

[Miklosovic, Stefan]

Hi list,

I would like to highlight this ticket (1). I hope we manage to merge it in the 
foreseeable future. It will be in cassanra-4.1 and in trunk. Once in, by 
default, if there are unused imports in Java code, ant build will fail.

There will be a workaround by which you can skip failing when imports are 
unused - by "-Dno-checkstyle=true" flag. It is there for local development when 
you are just not interested in having the code clean on imports. The check will 
be present for tests as well (same flag).

This should save us from going through the source code on reviews and writing 
these "nit: unused imports" and all imports will be used from now.

Please let me know if there are any concerns and if this workflow is fine for 
you.

​(1) 
https://issues.apache.org/jira/browse/CASSANDRA-17876

Regards,

Stefan Miklosovic

Re: Checkstyle will be updated to fail Ant build when unused imports are present in the code

[Miklosovic, Stefan]

I should add that "no-checkstyle" will turn off whole checkstyle for good. Not 
unused imports only. This is same logic as for javadocs - "no-javadoc" flag


From: Miklosovic, Stefan
Sent: Thursday, September 22, 2022 20:19
To: dev@cassandra.apache.org
Subject: Checkstyle will be updated to fail Ant build when unused imports are 
present in the code

Hi list,

I would like to highlight this ticket (1). I hope we manage to merge it in the 
foreseeable future. It will be in cassanra-4.1 and in trunk. Once in, by 
default, if there are unused imports in Java code, ant build will fail.

There will be a workaround by which you can skip failing when imports are 
unused - by "-Dno-checkstyle=true" flag. It is there for local development when 
you are just not interested in having the code clean on imports. The check will 
be present for tests as well (same flag).

This should save us from going through the source code on reviews and writing 
these "nit: unused imports" and all imports will be used from now.

Please let me know if there are any concerns and if this workflow is fine for 
you.

​(1) 
https://issues.apache.org/jira/browse/CASSANDRA-17876

Regards,

Stefan Miklosovic

Re: [VOTE] CEP-20: Dynamic Data Masking

[Josh McKenzie]

+1

On Thu, Sep 22, 2022, at 4:28 AM, Mick Semb Wever wrote:
> 
>> 
>> I'd like to propose CEP-20 for approval.
>> 
>> Proposal: 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
>> Discussion: https://lists.apache.org/thread/qsmxsymozymy6dy9tp5xw9gn5fhz9nt4
>> 
>> The vote will be open for 72 hours.
>> Votes by committers are considered binding.
>> A vote passes if there are at least three binding +1s and no binding vetoes.
> 
> 
> 
> +1
>