One issue with this approach is that we are advertising that we are preparing a
security release by preparing such a release candidate.
I wonder if we need to find a way to produce binaries without leaving an
obvious public mark (i.e. private CI, private branch)
From: Josh McKenzie
Date: Tues
+1
From: Branimir Lambov
Date: Wednesday, 16 February 2022 at 08:58
To: dev@cassandra.apache.org
Subject: [VOTE] CEP-19: Trie memtable implementation
Hi everyone,
I'd like to propose CEP-19 for approval.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+i
+1
The Simulator is hopefully going to be another powerful tool for this kind of
work, and we should be encouraging the use of both for large or complex pieces
of work.
From: Alex Petrov
Date: Wednesday, 16 February 2022 at 11:56
To: dev@cassandra.apache.org
Subject: Re: Apache Cassandra fuz
sts and build our knowledge of
> Harry. Regarding a migration of existing tests to it, I would wait a bit
> before choosing to go down that path.
>
>
>
> Le mer. 16 févr. 2022 à 16:30, bened...@apache.org a
> écrit :
>>
>> +1
>>
>>
>>
>
essed.
So I am +1 for starting to use it in our new tests and build our knowledge of
Harry. Regarding a migration of existing tests to it, I would wait a bit before
choosing to go down that path.
Le mer. 16 févr. 2022 à 16:30, bened...@apache.org<mailto:bened...@apache.org>
mailto:be
I agree that a new configuration layout should be introduced once only, not
incrementally.
However, I disagree that we should immediately deprecate the old config file
and refuse to parse it. We can maintain compatibility indefinitely at low cost,
so we should do so.
Users of the old format, w
At the very least we should wait until the current issues with CI have
resolved, so that pending work can merge, before declaring any freeze.
From: Mick Semb Wever
Date: Tuesday, 8 March 2022 at 15:13
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Next release cut
Should we plan some soft
Our style guide hasn’t been updated in about a decade, and I think it is
overdue some improvements that address some shortcomings as well as modern
facilities such as streams and lambdas.
Most of this was put together for an effort Dinesh started a few years ago, but
has languished since, in pa
ke8" style check shows many existing issues in the Python
code, including libraries imported but unused, redefinition of unused imports
and invalid escape sequence in strings.
On 14/03/2022 09:41, bened...@apache.org<mailto:bened...@apache.org> wrote:
Our style guide hasn’t been upda
:35AM +0000, bened...@apache.org wrote:
> Our style guide hasn’t been updated in about a decade, and I think it is
> overdue some improvements that address some shortcomings as well as modern
> facilities such as streams and lambdas.
>
> Most of this was put together for an effort
I am strongly in favour of deprecating python dtests in all cases where they
are currently superseded by in-jvm dtests. They are environmentally more
challenging to work with, causing many problems on local and remote machines.
They are harder to debug, slower, flakier, and mostly less sophistic
rtant limitation.
On Mon, 14 Mar 2022 at 12:24, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
I am strongly in favour of deprecating python dtests in all cases where they
are currently superseded by in-jvm dtests. They are environmentally more
challen
irection on if we should avoid making
method parameters and local variables `final` - this is inconsistent over the
code base, but I'd prefer not having them. If the method is large enough that
we might mistakenly reuse parameters/variables, we should probably refactor the
method.
/Marcus
On M
d to move to the previous line, but sometimes it makes the
line much too long due to some nested calls or something else.
On Mon, Mar 14, 2022 at 4:02 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
Hi Jacek,
> Sometimes, although it
that the current codebase is not consistent since
it was written over a long period of time so it tends to confuse folks who are
working in different parts of the codebase. So this style guide would be very
helpful.
On Mar 14, 2022, at 2:41 AM, bened...@apache.org<mailto:bened...@apache.org
:52 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
I’m a strong -1 on strictly enforcing any style guide. It is there to help
shape contributions, review feedback and responding to said feedback. It can
also be used to setup IntelliJ’s code formatter to configure default behavi
+1
From: Erick Ramirez
Date: Tuesday, 15 March 2022 at 22:08
To: dev@cassandra.apache.org
Subject: Re: [FOR REVIEW] Blog post: An Interview with Project Contributor,
Lorina Poland
Looks good to me! 🍻
On Wed, 16 Mar 2022 at 08:17, Chris Thornett
mailto:ch...@constantia.io>> wrote:
As requested
Since PRs are a second class citizen to Jira, mostly used for a scratch pad for
nits and questions with code context, I suspect any improvements here will need
to be automated to have any hope of success.
From: Stefan Miklosovic
Date: Wednesday, 16 March 2022 at 08:16
To: dev@cassandra.apache.o
+1, let’s change our merge strategy 😊
From: Josh McKenzie
Date: Wednesday, 16 March 2022 at 12:47
To: dev@cassandra.apache.org
Subject: Re: Using labels on pull requests in GitHub
I think the fact that they pile up is because our merge strategy means we don't
actually merge using the PR's we u
> I support this too… leads to more noise in, and less readability of, the
> patch.
Readability of the patch is not harmed with modern tooling (with whitespace
being highlighted differently to content changes).
Legibility of the code (not patch) should always be preferred IMO. To aid code
comp
> We are talking about one extra line, not a dozen or more.
I think you are confused about the context. The case I was discussing often
means 10+ additional lines at each call-site.
> Once the code gets more real, it is faster to read the difference between (a)
> and (c)
This isn’t a great exa
should also be specifying spacing for loop
guards, conditions, casts, etc?
From: bened...@apache.org
Date: Sunday, 20 March 2022 at 21:37
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
> We are talking about one extra line, not a dozen or more.
I think you
right now but I suspect we can get this in in April some time.
On Mon, Mar 14, 2022, at 8:36 AM,
bened...@apache.org<mailto:bened...@apache.org> wrote:
This is the limitation I mentioned. I think this is solely a question of
supplying an initial config that uses vnodes, i.e. that specifies m
e, since the implementations can diverge
>>> without being caught by tests.
>>>
>>> Is there any way we could avoid duplicating functionality on the test
>>> server and use the same initialization code on in-jvm dtests?
>>>
>>> [1] -
get up to speed with
writing in-jvm dtests and extending the framework.
Em ter., 29 de mar. de 2022 às 20:09,
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> escreveu:
It often does not work. I can attest to many wasted weeks, on some environments
never
I just did the same for cassandra-accord, I guess some config was lost in the
upgrade
https://issues.apache.org/jira/projects/INFRA/issues/INFRA-23074
From: Mick Semb Wever
Date: Monday, 4 April 2022 at 08:55
To: dev@cassandra.apache.org
Subject: Re: [GitHub] [cassandra-website] ossarga comme
The property you are setting permits some kinds of privilege escalation, but by
default classes outside of those pre-defined by the whitelist are not
permitted. This is imposed here:
https://github.com/apache/cassandra/blob/210793f943dc522161fd26b6192f38a5c83fa131/src/java/org/apache/cassandra/c
One reason might be compatibility – this may (I hope _will_) migrate to a
simple integer of low cardinality in future, which would be a breaking change.
This identifier will likely be used by Accord for correctness, too, and doing
something wrong with it could have severe consequences, so at the
this if there are concerns about it.
Em qua., 27 de abr. de 2022 às 14:51,
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> escreveu:
One reason might be compatibility – this may (I hope _will_) migrate to a
simple integer of low cardinality in future
I think this is close to what we settled on last we hashed this out.
From: Josh McKenzie
Date: Monday, 9 May 2022 at 22:47
To: dev@cassandra.apache.org
Subject: Re: How we flag tickets as blockers during freeze
As you mentioned on slack, we can introduce FixVersions for the unreleased
interim v
the wiki.
From: bened...@apache.org
Date: Monday, 14 March 2022 at 09:41
To: dev@cassandra.apache.org
Subject: Updating our Code Contribution/Style Guide
Our style guide hasn’t been updated in about a decade, and I think it is
overdue some improvements that address some shortcomings as well as
own experience it
makes it easier to read if we uniformly used braces everywhere, but it does
look like there are quite a few places in the code where we have unbraced ifs
Overall the doc is well written and carefully considered, and I appreciate all
of the work that went int
:45
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
On Sat, May 14, 2022 at 8:24 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> I'm in favor of codifying the usage of @NotNull and @Nullable styli
I agree with this sentiment, but I think it will require a bit of time to
figure out where that balance is.
I’ve inserted a mention of @Nullable, @ThreadSafe, @NotThreadSafe and
@Immutable.
> If we only use one of the two - for example @Nullable - that leaves us with
> "We know the original au
Any more feedback around this? Everyone happy with the latest proposal?
From: bened...@apache.org
Date: Sunday, 15 May 2022 at 15:08
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
I agree with this sentiment, but I think it will require a bit of time to
c and they may exist since
early versions for example.
Best regards,
Ekaterina
On Mon, 30 May 2022 at 14:10, Derek Chen-Becker
mailto:de...@chen-becker.org>> wrote:
Looks great!
On Mon, May 30, 2022, 5:37 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org&
to have it explicitly stated.
Regards
On Tue, 31 May 2022 at 14:46, bened...@apache.org wrote:
>
> I think that it is hard to define what the right extent of a patch is, but it
> should be the minimal scope that the author feels sufficient to safely
> address the concerns of the patch. I ha
I’ve modified just the first sentence, to:
Dependencies expose the project to ongoing audit and maintenance burdens, and
security risks. We wish to minimise our declared and transitive dependencies
and to standardise mechanisms and solutions in the codebase. Adding new
dependencies requires com
Somebody hasn’t looked at the new style guide*, the conversation for which
keeps rolling on and so it never quite gets promoted to the wiki. It says:
Always use @Override annotations when implementing abstract or interface
methods or overriding a parent method.
*
https://docs.google.com/docume
: [DISCUSS] Change code style guide WRT to @Override in subclasses /
interface implementations
I don’t think the guide has yet been published to the official website, has it?
Maybe we should just get it out there.
On Jun 3, 2022, at 8:54 AM, bened...@apache.org wrote:
Somebody hasn’t looked at the
guidance but I
think it’s in a good enough shape to publish.
On Jun 3, 2022, at 9:07 AM, bened...@apache.org wrote:
I always ask if we’re ready, get a few acks, then one or two new queries come
out of the woodwork.
Perhaps I will just publish, and we can start addressing these queries in a
> The returned result set is after the updates are applied?
Returning the prior values is probably more powerful, as you can perform
unconditional updates and respond to the prior state, that you otherwise would
not know. It’s also simpler to implement.
My inclination is to require that SELECT
> 1. Dependant SELECTs
> 2. Dependant UPDATEs
> 3. UPDATE from secondary index (or SASI)
> 5. UPDATE with predicate on non-primary key
So, I think these are all likely to be rejected the same way they are today, as
the individual statements would not parse [1,2] or be validated [3,5], as I’m
fai
e
to be submitted in one statement block?
I'll stop here for now.
Patrick
On Sat, Jun 4, 2022 at 3:34 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> The returned result set is after the updates are applied?
Returning the prior values
> One way to make it obvious is to require the user to explicitly type the
> SELECTs and then to require that all SELECTs appear before
> UPDATE/INSERT/DELETE.
Yes, I agree that SELECT statements should be required to go first.
However, I think this is sufficient and we can retain the shorter f
d just return the select.
Thanks,
Blake
On Jun 6, 2022, at 9:41 AM, Henrik Ingo
mailto:henrik.i...@datastax.com>> wrote:
On Mon, Jun 6, 2022 at 5:28 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> One way to make it obvious is to requi
en the user has requested we return the post-update state of the cell.
On Jun 6, 2022, at 4:00 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
> if multiple updates end up touching the same cell, I’d expect the last one to
> win
Hmm, yes I suppose range tombstones are a pla
: [DISCUSS] Change code style guide WRT to @Override in subclasses /
interface implementations
sounds good. Lazy consensus it is.
On Jun 4, 2022, at 11:09 AM, bened...@apache.org wrote:
I think lazy consensus is good enough here, since there has been no dissent so
far as I can tell. It’s easier to
ermediate values would be straightforward to calculate though.
On Jun 6, 2022, at 4:33 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
It affects not just RETURNING but also conditions that are evaluated against
the row, and if we in future permit using the values from one select
... WHERE key=2;
ELSE
UPDATE ... SET ... WHERE key=3;
ENDIF
COMMIT TRANSACTION;
Which would make the proposed COMMIT IF we're talking about now a shorthand. Of
course this would be follow on work.
On Jun 8, 2022, at 1:20 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
I i
to us
ultimately), but it feels like a nicer API for the user – depending on how
these exceptions are surfaced in client APIs.
From: bened...@apache.org
Date: Friday, 10 June 2022 at 19:59
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
So, thinking on it myself
existing CQL
syntax. (SQL Example using JDBC: https://www.baeldung.com/java-jdbc-auto-commit)
Path 2)
Chart a new direction with new syntax
I genuinely don't have a clear answer, but I would love hearing from people on
what they think.
Patrick
On Fri, Jun 10, 2022 at 12:07 PM
bened...@apache.o
s submitted multiple
times due to a connection time-out or other connectivity issue. I have no idea
how that is implemented under the hood and I don’t even know if this is
technically possible with the Accord design, but I thought it would be
interesting to think about.
Best regards,
Boxuan
O
I believe that is a MySQL specific concept. This is one problem with mimicking
SQL – it’s not one thing!
In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL value
submitted to a Boolean operator yields UNKNOWN.
IF (X) THEN Y does not run Y if X is UNKNOWN;
IF (X) THEN Y ELSE
’s not one thing!
Right?!?! As if this needed to be more complex.
I think we have evidence that it is fine to interpret NULL as “false” for the
evaluation of IF conditions.
Agree. Null == false isn't too much of a leap.
Thanks for taking up the charge on this one. Glad to see it moving
a leap.
Thanks for taking up the charge on this one. Glad to see it moving forward!
Thanks,
Aaron
On Sun, Jun 12, 2022 at 10:33 AM
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
Welcome Li, and thanks for your input
> When I first saw the
DATE cars SET car.next_service = 10 WHERE ... AS car
COMMIT TRANSACTION
Cheers,
Derek
On Sun, Jun 12, 2022 at 5:34 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> I would love hearing from people on what they think.
^^ It would be grea
ore complex.
I think we have evidence that it is fine to interpret NULL as “false” for the
evaluation of IF conditions.
Agree. Null == false isn't too much of a leap.
Thanks for taking up the charge on this one. Glad to see it moving forward!
Thanks,
Aaron
On Sun, Jun 12, 2022 at 10:3
TRANSACTION
I prefer it to if...abort and commit if ... isn't popular.
On Jun 13, 2022, at 4:14 PM, bened...@apache.org<mailto:bened...@apache.org>
wrote:
> Like I mentioned in my earlier email, the if/abort syntax throwing an
> exception would, at least as described, limit use
oncern is how we can start getting incremental
improvements into end users' hands more quickly, since the alternative right
now is to basically roll your own, right?
Cheers,
Derek
On Mon, Jun 13, 2022 at 4:16 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org&
was in reference to the "Would you require a LIMIT 1 clause if the
key did not fully specify a row?" question, so I think we're in agreement here.
Cheers,
Derek
On Tue, Jun 14, 2022 at 1:27 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>
(or 3. Let schema updates break the statement – this might actually be
preferable, so long as it fails-fast rather than corrupts behaviour)
From: bened...@apache.org
Date: Tuesday, 14 June 2022 at 20:58
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
It sounds
+1
From: Blake Eggleston
Date: Tuesday, 14 June 2022 at 21:46
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
I'd lean towards 3, where the statement doesn't parse because `miles` is
ambiguous
On Jun 14, 2022, at 1:40 PM, bened...@apache.org<
Osipov
Date: Wednesday, 15 June 2022 at 14:04
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
* bened...@apache.org [22/06/15 10:00]:
> It sounds like we’re zeroing in on a solution.
>
> To draw attention back to Jon’s email, I think the last open questio
> I agree a broader consensus beyond those on the jira ticket should be sought
> before committing the patch that bumps a new major.
Broader consensus should be sought on any ticket that breaks backwards
compatibility – even if we already have bumped major version.
A major version bump should N
e?
From: Konstantin Osipov
Date: Wednesday, 15 June 2022 at 20:56
To: dev@cassandra.apache.org
Subject: Re: CEP-15 multi key transaction syntax
* bened...@apache.org [22/06/15 18:38]:
> I expect LET to behave like SELECT, and I don’t expect this work to modify
> the behaviour of normal
201 - 266 of 266 matches
Mail list logo
