Re: [DISCUSS] LWT UPDATE semantics with + and - when null

2022-08-30 Thread Caleb Rackliffe
Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1 (depending on the type) in our previous discussion, but for some reason didn't bring up the SQL analog :-| On Tue, Aug 30, 2022 at 5:38 PM Benedict wrote: > I’m a bit torn here, as consistency with counters is important. Bu

Re: [DISCUSS] Removing support for java 8

2022-08-30 Thread Caleb Rackliffe
+1 on removing 8 for trunk On Tue, Aug 30, 2022 at 2:42 PM Jon Haddad wrote: > +1 to removal of 8 in trunk. > > On 2022/08/29 20:09:55 Blake Eggleston wrote: > > Hi all, I wanted to propose removing jdk8 support for 4.1. Active > support ended back in March of this year, and I believe the commun

Re: [DISCUSS] LWT UPDATE semantics with + and - when null

2022-08-30 Thread Benedict
I’m a bit torn here, as consistency with counters is important. But they are a unique eventually consistent data type, and I am inclined to default standard numeric types to behave as SQL does, since they write a new value rather than a “delta” It is far from optimal to have divergent behaviou

[DISCUSS] LWT UPDATE semantics with + and - when null

2022-08-30 Thread David Capwell
4.1 added the ability for LWT to support "UPDATE ... SET name = name + 42", but we never really fleshed out with the larger community what the semantics should be in the case where the column or row are NULL; I opened up https://issues.apache.org/jira/browse/CASSANDRA-17857 for this issue. As I se

Re: [DISCUSS] Removing support for java 8

2022-08-30 Thread Jon Haddad
+1 to removal of 8 in trunk. On 2022/08/29 20:09:55 Blake Eggleston wrote: > Hi all, I wanted to propose removing jdk8 support for 4.1. Active support > ended back in March of this year, and I believe the community has built > enough confidence in java 11 to make it an uncontroversial change for

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

2022-08-30 Thread Benedict
Not to push the point too strongly (I don’t have a very firm view of my own), but if we provide this via a view feature we’re just implementing one new feature and we get masking for free. I don’t think it is materially more complicated than redefining columns for users - it might even be less s

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

2022-08-30 Thread Andrés de la Peña
> > GRANT SELECT ON foo.unmasked_name TO top_secret; Note that Cassandra doesn't have support for column-level permissions. There was an initiative to add them in 2016, CASSANDRA-12859 . However, the ticket has been inactive since 2017. The l

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

2022-08-30 Thread Avi Kivity via dev
Agree with views, or alternatively, column permissions together with computed columns: CREATE TABLE foo (   id int PRIMARY KEY,   unmasked_name text,   name text GENERATED ALWAYS AS some_mask_function(text, 'xxx', 7) ) (syntax from postgresql) GRANT SELECT ON foo.name TO general_use; G

Re: [DISCUSS] Removing support for java 8

2022-08-30 Thread Brad
+1 on removing jdk8. We should also remove python 3.6 (EOL 12/21) on trunk at the same time. On Mon, Aug 29, 2022 at 9:40 PM Blake Eggleston wrote: > Sorry, I meant trunk, not 4.1 :) > > > On Aug 29, 2022, at 1:09 PM, Blake Eggleston > wrote: > > > > Hi all, I wanted to propose removing jdk8 s

Re: [DISCUSS] Removing support for java 8

2022-08-30 Thread Benjamin Lerer
I seem to recall some discussion about the fact that we took some shortcuts when introducing java11 support. Before removing java8 support we should probably make sure that we have cleaned those things. My understanding was that it would be part of the work related to adding support for java 17 but