Hi Maulin,
This sounds fine to me, though I don’t consider myself well versed in these
system details.
I have a meta comment though: I think this could easily have been a Jira with a
DISCUSS thread brought to the list. The CEP process is (in my opinion) for
complex decisions that needs broad c
t; > the coordination is handled up front in the sequencing step. Glass half
> > empty: even single-row reads and writes have to pay the full coordination
> > cost. Fauna has optimized this away for reads but I am not aware of a
> > description of how they changed the desi
actions with unknown read/write set, as I outlined in the email to
kick off this thread.
On Sun, Oct 10, 2021 at 4:05 AM bened...@apache.org
wrote:
> Hi Jonathan,
>
> I will summarise my position below, that I have outlined at various points
> in the other thread, and then I would
Cassandra transaction management
On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org
wrote:
> If we want to fully unpack this particular point, as far as I can tell
> claiming ANSI SQL would indeed require interactive transactions in which
> arbitrary conditional work may be performed by
f other
> ways, I’m sure, but CEP-15 is what’s on offer for Cassandra at the moment,
> and I’m not seeing any alternative CEPs with folks lined up to implement
> them.
>
> The CEP is a clear and meaningful improvement over status quo. The
> engineers behind it are committed to
Hi Alex,
I hugely value and respect your input here, but I think in this case you may be
mistaken.
Postgres[1] makes explicit that subsequent SELECT statements may see different
data, and SQL Server[2] does the same. I believe the Oracle documents you
reference do the same, but are more obtuse
meaningful detail?
>
> > On Oct 11, 2021, at 6:34 PM, Jonathan Ellis wrote:
> >
> > On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org >
> > wrote:
> >
> >> If we want to fully unpack this particular point, as far as I can tell
> >> claiming ANSI
(like Calvin, and for distributed consensus protocols) to serialize their
execution, unless I’m missing something.
Otherwise I agree entirely with your email, now I’ve read it 😊
From: bened...@apache.org
Date: Wednesday, 13 October 2021 at 08:52
To: dev@cassandra.apache.org
Subject: Re
> In the context of Cassandra, I had actually assumed the Accord timestamp will
> be used as the cell timestamp for each value? Isn't something like this
> needed for compaction to work correctly too?
Yes, though we are likely to apply some kind of compression to the timestamp,
as global timest
> It seems like potentially every statement now needs to go through the Accord
> consensus
protocol, and this could become expensive, where my goal was to design the
simplest and most lightweight example thinkable. BUT for read-only Accord
transactions, where I specifically also don't care about s
Date: Wednesday, 13 October 2021 at 15:50
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
On Wed, Oct 13, 2021 at 2:54 PM bened...@apache.org
wrote:
> I think this is a blurring of lines of systems however. I _think_ the
> point Alex is making (corr
t; is also reasonable) and (2) SQL with
interactive transactions.
I'd prefer to keep the discussion on the mailing list, thanks.
On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org
wrote:
> Jonathan,
>
> Your request to separate consensus from execution is about as sensical as
> ask
Hi everyone,
I would like to start a vote on this CEP, split into three sub-decisions, as
discussion has been circular for some time.
1. Do you support adopting this CEP?
2. Do you support the transaction semantics proposed by the CEP for Cassandra?
3. Do you support an incremental approach to d
ensus (3 binding +1 votes and no binding
> vetoes). The vote should remain open for 72 hours."
>
> No provision is made for declaring a CEP, or part of it, to be subject to
> a simple majority vote simply by claiming it's directional.
>
>
> On Thu, Oct 14, 2021 at 11:32 A
e give
up global serializability like LWT" is also reasonable) and (2) SQL with
interactive transactions.
I'd prefer to keep the discussion on the mailing list, thanks.
On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org
wrote:
> Jonathan,
>
> Your request to separate consens
ngaging in
hypotheticals around how "we could enhance Accord with X."
On Thu, Oct 14, 2021 at 12:46 PM bened...@apache.org
wrote:
> > Calvin supports arbitrarily complex transactions (included dependent
> statements and indexed reads and writes), executed in parallel, with
> loc
Mick,
With respect, I would appreciate it if you would re-read the discussion in
full. I have been in discussion with Jonathan for a month with no progress. I
have still not received answers to simple questions I have posed on multiple
times over a dozen emails (see below), all of which I consi
> valuing community over code
“Community” involves treating others with respect: following the norms of
conversation by acknowledging and responding to the points and queries of
others, accepting when you have a minority position, and stepping aside when
your goals are not clearly in conflict w
Hi Jonathan,
This clarifying change has been incorporated.
If you both rescind your veto, we have time to rescue this vote.
From: Jonathan Ellis
Date: Friday, 15 October 2021 at 19:11
To: dev
Subject: Moving CEP-15 forward
Hi all,
We have had several discussions today as to how to move forwa
Purpose Transactions
1. +1(nb)
2. +1(nb)
3. +1(nb)
> On Oct 17, 2021, at 5:19 AM, Gary Dusbabek wrote:
>
> +1 for all three.
>
>> On Thu, Oct 14, 2021 at 11:31 AM bened...@apache.org
>> wrote:
>>
>> Hi everyone,
>>
>> I would like to start a
I think this would be fine if there were a way for approval of later steps to
trigger the build automatically. As it is we have to traverse the dependency
graph manually, which is a bit weird.
I can’t figure out a way to do this with the CircleCI API however. It might be
a feature request, and
current workflow and approval required
> but if it is not acceptable to others and skipping the build approval click
> is what others would prefer, I will open a ticket to restore that part.
> Please let me know and one more time, apologize for missing your email,
> Alex.
>
> Best r
and did something like the below
> > while we compile then the burden to maintain doesn’t exist
> > >
> > > # remove comments and empty lines
> > > $ egrep -v '^[[:space:]]*#|^[[:space:]]*$' conf/cassandra.yaml.doc >
> > conf/cassandra.yaml
&
Hi Jeremiah,
My personal view is that work to modularise the codebase should be tied to
specific use cases. If improved testing is the purpose of this work, I think it
would help to include those improved tests that you plan to support as goals
for the CEP.
If on the other hand some of this wo
that were discussed but not yet voted on. I don't know if this adds to
cognitive load for anyone else than myself.)
henrik
On Mon, Oct 25, 2021 at 12:39 PM bened...@apache.org
wrote:
> Hi Jeremiah,
>
> My personal view is that work to modularise the codebase should be tied to
>
I think it is probably acceptable to prevent downgrades once a new feature is
enabled, as the exposure risk is limited to that one feature. The user can test
the new version to ensure everything else works satisfactorily before
committing to this one feature.
A downgrade tool would also be poss
t
> tickets? Or do people prefer to have a discussion/vote on the idea of
> improving the modularity of the code base in general?
>
> -Jeremiah
>
> > On Oct 25, 2021, at 9:26 AM, bened...@apache.org wrote:
> >
> > Thanks Henrik for the additional context.
>
them as needed for future work. I think having the
> > interfaces actually improves on our ability to do so without breaking other
> > parts of the code. My suggestion would be that we try not to make such
> > changes in patch releases if possible, but again I wouldn’t let that
We can also ByteWeave System.exit away, or migrate it to some other method
invocation that e.g. throws an exception.
The simulator makes extensive use of byte weaving on top of the dtest api. It
should be landing soon, and we could repurpose some of its code for regular
dtests. Or we may want t
> I am -1 here, for the reasons listed above; the problem (in my eye) is not
> reader/writer but higher level at the actual SSTable. If we plug out
> read/write but still allow direct file access, then these abstractions fail
> to provide the goals of the CEP.
Be careful dropping -1s, as your
+1
From: Mick Semb Wever
Date: Friday, 29 October 2021 at 13:45
To: dev@cassandra.apache.org
Subject: [VOTE] Release dtest-api 0.0.11
Proposing the test build of in-jvm dtest API 0.0.11 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=re
> How do we define what "releasable trunk" means?
For me, the major criteria is ensuring that work is not merged that is known to
require follow-up work, or could reasonably have been known to require
follow-up work if better QA practices had been followed.
So, a big part of this is ensuring we
> having them only configured via yaml seems like a bad outcome
+1
I would like to see us move towards configuration being driven through virtual
tables where possible, so that the whole cluster can be managed from a single
interface. Not sure if this is the right place to bite this off, but pe
The largest number of test failures turn out (as pointed out by David) to be
due to how arcane it was to trigger the full test suite. Hopefully we can get
on top of that, but I think a significant remaining issue is a lack of trust in
the output of CI. It’s hard to gate commit on a clean CI run
I agree that we don’t need to block the CEP on this, and that we should have
that discussion. But it’s worth noting that the CEP should not anticipate or
depend on any specific outcome of that discussion.
Since it is somewhat relevant for this discussion, my view is that no interface
should be
t needs to work
and what doesn’t, and without the broader set of committers knowing this then
the likely hood any new API will break in a minor is high.
> On Nov 9, 2021, at 12:13 PM, bened...@apache.org wrote:
>
> I agree that we don’t need to block the CEP on this, and that we should
+1
From: Brandon Williams
Date: Monday, 15 November 2021 at 19:47
To: dev@cassandra.apache.org
Subject: Re: [VOTE] CEP-17: SSTable format API
+1
On Mon, Nov 15, 2021 at 1:43 PM Branimir Lambov wrote:
>
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
> https://cwiki.a
If decrypting before transmission we’ll want to require the cluster to have an
internode authenticator setup, else a nefarious process could simply ask for
data to be streamed to it to circumvent the encryption.
I agree it would be nice to have the nodes share the secret some way to avoid
the a
I assume the key would be decrypted before being streamed, or perhaps encrypted
using a public key provided to you by the receiving node. This would permit
efficient “zero copy” streaming for the data portion, but not require any
knowledge of the recipient node’s master key(s).
Either way, we w
16/11/2021 10:50, bened...@apache.org wrote:
> I assume the key would be decrypted before being streamed, or perhaps
> encrypted using a public key provided to you by the receiving node. This
> would permit efficient “zero copy” streaming for the data portion, but not
> require any
encryption when on-disk encryption is enabled. It's definitely a
valid use case to have Cassandra over IPSec without enabling TLS.
On 16/11/2021 12:02, bened...@apache.org wrote:
> We already have the facility to authenticate peers, I am suggesting we should
> e.g. refuse to enable encryption
I raised this before, but to highlight it again: how do these approaches
interface with our merge strategy?
We might have to rebase several dependent merge commits and want to merge them
atomically. So far as I know these tools don’t work fantastically in this
scenario, but if I’m wrong that’s
I agree with Joey that most users may be better served by OS level encryption,
but I also think this ticket can likely be delivered fairly easily. If we have
a new contributor willing to produce a patch then the overhead for the project
in shepherding it shouldn’t be that onerous. If we also hav
ing query eligibility at the protocol level.
Does anyone have any thoughts about this?
From: bened...@apache.org
Date: Wednesday, 6 October 2021 at 14:48
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
This is a very good point. I forget the reason
For those who are interested, this work has been posted as CASSANDRA-17164.
From: bened...@apache.org
Date: Wednesday, 1 September 2021 at 05:29
To: dev@cassandra.apache.org
Subject: Re: [VOTE] CEP-14: Paxos Improvements
With 10 +1 votes and no -1 votes, the vote passes. Thanks everyone!
From
t existing clients without needing any changes. I do think just
> having a new per statement CQL option is not a great choice. Though the
> limitations of how 2/3 could be implemented make me think the “per request
> custom payload” may actually be the option that is the most u
This is the approach I favour for config files also. We had a much less engaged
discussion on this topic only a few months ago, so glad to see more people
getting involved now.
I would however personally prefer to see the configuration file slowly
deprecated (if perhaps never retired), in favou
file?
Le ven. 26 nov. 2021 à 15:40, bened...@apache.org a
écrit :
> This is the approach I favour for config files also. We had a much less
> engaged discussion on this topic only a few months ago, so glad to see more
> people getting involved now.
>
> I would however personally pr
ned version.
> > If we support both formats, the question would be: what should be the one
> > used by default in the configuration file?
> >
> > Le ven. 26 nov. 2021 à 15:40,bened...@apache.org
> a
> > écrit :
> >
> >> This is the approach I favour for
FYI, CASSANDRA-17008 (the main element of CEP-10) is ready to merge, in case
anybody still plans to take a look. Otherwise it will land in a day or two.
From: bened...@apache.org
Date: Friday, 30 July 2021 at 14:27
To: dev@cassandra.apache.org
Subject: [RESULT] [VOTE] CEP-10: Cluster and Code
021 at 17:32
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Nested YAML configs for new features
On Mon, Nov 29, 2021 at 11:51 AM bened...@apache.org
wrote:
>
> Maybe we can make our query language more expressive 😊
>
> We might anyway want to introduce e.g. a LIKE filtering op
es, and Properties.flatten would turn every property into a “flatten”
> version (isScalar (isPrimitive or not hasSubProperties) or isCollection).
> This doesn’t solve 100% of the issues that vtable has (types such as Duration
> would need additional translation as they are Scalar but n
I’m in favour, though I have weaker requirements for backports than others.
This work is pretty significant, though. It’s nothing like the complexity of
CEP-14, but it heavily modifies a critical piece of the system. I would say
that it needs a rigorous review process if it’s going into a patch
one as well
(PR in CASSANDRA-17166 shows this working) if users desire it; so we get the
consistency of nested, and the “grep” benefits of flat.
> On Nov 29, 2021, at 2:17 PM, bened...@apache.org wrote:
>
> If we’re thinking of moving towards nested configuration, then before
> employ
, bened...@apache.org
wrote:
> The problem with scoping this to “features” is that we end up with at best
> local coherence. The config file as a whole will end up just as incoherent
> through its design evolution as it has historically.
>
> If you take a look at my proposed layout
I think you were correct to start a DISCUSS thread, Bowen. You should not start
a vote until you have first established if there is consensus.
Also, I agree with the proposal.
From: Bowen Song
Date: Saturday, 4 December 2021 at 23:12
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Disablin
> As the repair is only guaranteed for a majority of replicas, I assume I
can discover somewhere which replicas are up to date like this?
I’m not quite sure what you mean. Do you mean which nodes have participated in
a paxos repair? This information isn’t maintained, but anyway would not imply
t
in CEP-14
On Sun, 5 Dec 2021, 1.45 bened...@apache.org, wrote:
> > As the repair is only guaranteed for a majority of replicas, I assume I
> can discover somewhere which replicas are up to date like this?
>
> I’m not quite sure what you mean. Do you mean which nodes have
> partic
org
Subject: Re: Paxos repairs in CEP-14
On Sun, 5 Dec 2021, 18.40 bened...@apache.org, wrote:
> > And at the end of the repair, this lower bound is known and stored
> somewhere?
>
> Yes, there is a new system.paxos_repair_history table
>
> > Under good conditions, I assume
runk. Bears
>> thinking more deeply about.
>>
>> I'd also be game for revisiting our merge strategy. I don't see much
>> difference in labor between merging between branches vs. preparing separate
>> patches for an individual developer, however I'm sure the
reen
> >>>
> >>> Phase 2:
> >>> * Add Harry to recurring run against trunk
> >>> * Add Harry to release pipeline
> >>> * Suite of perf tests against trunk recurring
> >>>
> >>>
> >>>
> >>> On Wed, Nov 1
Does this work with trunk patches that involve other branches as well? I’d
imagine we have the same problem. Or are we proposing limiting this feature to
trunk _only_ patches? If so, that seems rather weak.
From: Brandon Williams
Date: Thursday, 9 December 2021 at 20:25
To: dev@cassandra.apache
> It makes sense that such bug tickets are incentivised to be minimal, and if
> there is a smarter way (improvement) in trunk that is a separate follow-up
> ticket and patch
Are you proposing separating the work entirely, so that we don’t merge up to
trunk at all, or do a no-op merge? Often thi
Yeah, I positively dislike merge commits, both from a patch preparation
perspective and when trying to piece together a class’ history. It can actively
obfuscate the impact to the branch being looked at, as well as make it much
harder to skim the git log.
I’d vote to modify our merge strategy i
I don’t really see the advantage to this over 4.1.0-SNAPSHOT1
From: Mick Semb Wever
Date: Thursday, 16 December 2021 at 15:04
To: dev@cassandra.apache.org
Subject: [DISCUSS] Periodic snapshot publishing with minor version bumps
Back in January¹ we agreed to do periodic snapshot publishing, as we
etty simple
> way to accomplish it.
> >
> > Another option would be to push and tag a commit outside of the trunk
> branch that has the version as 4.1.0-pre1 or something. From my look at
> the CassandraVersion code something after SNAPSHOT will not parse
> correctly, -SNA
> It's not semantic versioning
Thought I’d check this, and this appears to be incorrect. From
https://semver.org:
A pre-release version MAY be denoted by appending a hyphen and a series of dot
separated identifiers immediately following the patch version. Identifiers MUST
comprise only ASCII a
December 2021 at 17:43
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps
On Thu, Dec 16, 2021 at 11:38 AM bened...@apache.org
wrote:
>
> > Oh yeah, that's a dealbreaker then. Wasn't aware.
>
> Is this a dealbreake
> No. You refer to Pre-release but my statement was about Build Metadata. The
timestamping of snapshots is the latter.
So you agree the proposal is compatible with semver? If so, what’s the problem?
I’m genuinely perplexed.
> I would rather bump the versions during the dev cycle and work on fixi
not parse correctly,
-SNAPSHOT needs to be the last thing. So 4.1.0-pre1-SNAPSHOT is valid,
4.1.0-SNAPSHOT-pre1 is not.
-Jeremiah
> On Dec 16, 2021, at 9:33 AM, bened...@apache.org wrote:
>
> I don’t really see the advantage to this over 4.1.0-SNAPSHOT1
>
> From: Mick Sem
> I would like to point out that the code and tests do not support "pre" as a
pre-release label. 4.1.0-pre1 would break the code.
If true this can easily be fixed, but AFAICT CassandraVersion is happy to parse
this just fine so I doubt there would be many breakages.
> using a pre-release version
Unfortunately it still arrived in my junk mail folder ☹
From: Bowen Song
Date: Tuesday, 21 December 2021 at 12:02
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Disabling MIME-part filtering on this mailing list
I have just received a confirmation from Infra informing me that this
change h
> Nevertheless, it requires fixes
I have run all tests successfully against 4.1.0-PRE1, without modification[1].
> more importantly requires others in the ecosystem to adapt
There is no such requirement for publishing these as alphas, but without
evidence to the contrary I doubt the downstream
After much discussion, I see three basic categories of approach:
A) distinguish releases using unstable release suffixes only
B) distinguish releases using some version number modification
C) distinguish releases using some version number modification AND unstable
release suffixes to indicate the
(I’ve taken this off list for now)
From: Bowen Song
Date: Tuesday, 21 December 2021 at 18:29
To: bened...@apache.org
Cc: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Disabling MIME-part filtering on this mailing list
Hmm, that's a bit unexpected.
Could you please have a look at the
The purpose of indicative votes is to seek input from the broader community.
There is no deadline, it is not an official vote, and can run across the
holiday period. Discussion can continue in parallel, but I do not get the
impression many others are very invested in this discussion. Certainly,
>The problem I have with (A2) is that third-parties, vendors, etc, can only
>clumsily extend and continue on those version numbers. 4.1.0-alpha2-myvendor-3
>is awkward.
Do you intend to use this capability, and if so could you point out where you
highlighted this motivation previously?
These s
> If we simply used CassandraVersion (which is broadly equivalent, but
> standard’s compliant)
Actually it’s got the same issue, but it’s a one line fix.
From: Mick Semb Wever
Date: Tuesday, 21 December 2021 at 22:06
To:
Cc: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Periodic snapshot pu
> Yeah, not described enough in this thread, it is part of the motivation to
> the proposal
I don’t believe it has been mentioned once in this thread. This should have
been clearly stated upfront as a motivation. Thus far no positive case has been
made on this topic, we have instead wasted a lo
> You were part of that slack thread, so it was a bad presumption on my behalf.
I am flattered, but I’m sure your intention was in fact to involve everyone in
this discussion. As it happens, I commented only on the end of that lengthy
thread and did not participate in the section you linked, so
That all sounds terribly complicated to me.
My view is that we should switch to the branch strategy outlined by Henrik (I
happen to prefer it anyway) and move to GitHub integrations to control merge
for each branch independently. Simples.
From: David Capwell
Date: Tuesday, 4 January 2022 at 2
headache enough when it goes wrong).
From: bened...@apache.org
Date: Tuesday, 4 January 2022 at 23:52
To: David Capwell , Joshua McKenzie
Cc: Henrik Ingo , dev
Subject: Re: [DISCUSS] Releasable trunk and quality
That all sounds terribly complicated to me.
My view is that we should switch to the
> If you see a merge commit in the history, isn't it normal to presume that it
> will contain the additional change for that branch for the parent commit
> getting merged in?
Sure, but it is exceptionally non-trivial to treat the work as a single diff in
any standard UX. In practice it becomes
t we don't forget to apply something to all branches
+(?) Is the devil we know
That's a lot of negatives for a very fixable single positive and some FUD.
On Tue, Jan 4, 2022 at 7:01 PM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
To
-4.0 .
git commit
From: bened...@apache.org
Date: Wednesday, 5 January 2022 at 21:07
To: Mick Semb Wever
Cc: dev
Subject: Re: [DISCUSS] Releasable trunk and quality
> If you see a merge commit in the history, isn't it normal to presume that it
> will contain the additional chan
I was sort of hoping we would retire the python dtests before long, at least in
large part (probably not ever entirely, but 99%).
I think many of them could be migrated to in-jvm dtests without much effort. I
would hate to expend loads of effort modernising them when the same effort
could see t
ompletely agree, however this is something someone would have to take on as
an effort and I don't believe I've seen anybody step up yet. At the current
rate we're going to be dragging along the python dtests into perpetuity.
On Wed, Jan 26, 2022 at 8:16 AM bened...@apache.
ts much more quickly, and debug failures much more easily.
Please Yes. If we can get away from python upgrade tests I think all our lives
would be improved.
I like it.
On Wed, Jan 26, 2022 at 8:42 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrot
powerful
tests that are also able to execute faster (for reasons of integration, not
language).
From: Brandon Williams
Date: Wednesday, 26 January 2022 at 16:09
To: dev
Subject: Re: Have we considered static type checking for our python libs?
On Wed, Jan 26, 2022 at 7:43 AM bened...@apache.org
I’m going to be a killjoy and once again query what value changing build system
brings, that outweighs the disruption to current long-term contributors that
can easily get things done today?
At the very least there should be a ranked choice vote that includes today’s
build system.
From: Maulin
that it is the case.
Le jeu. 3 févr. 2022 à 09:32, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> a écrit :
I’m going to be a killjoy and once again query what value changing build system
brings, that outweighs the disruption to current long-term contributo
rigger
another discussion about that.
Le jeu. 3 févr. 2022 à 10:17, bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> a écrit :
I don’t have a super strong desire to stay with ant, I just have a desire not
to unduly burden the project with unnecessary churn. Tool
s and downsides
of adopting a new build tool, to allow the community to decide whether the
change is worth pursuing.
Em qui., 3 de fev. de 2022 às 07:28,
bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> escreveu:
> Aleksei has proven that he was able to d
, 2022 at 3:23 AM bened...@apache.org wrote:
> If we’re struggling to actually use ant how we want that’s another matter,
> but it’s easy to forget how much just works for us with ant
If you don't regularly work on the build system, it may be easy to
forget that ant works by actually t
o:dri...@gmail.com>> wrote:
On Thu, Feb 3, 2022 at 7:19 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> It pretends to be Maven for dependency management, but this is a small part
> of the job of a build file.
It doesn't pretend,
I don’t have a strong opinion about CEP-7 taking a hard dependency on any new
CQL CEP, particularly from a point of view of first landing in the codebase.
From: Henrik Ingo
Date: Monday, 7 February 2022 at 12:03
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-7 Storage Attached Index
T
FWIW, I think the proposed approach to configuration is fine.
I think selecting a choice for the user should be done simply and
deterministically. We should probably default to Trie based memtables for users
with a fresh config file, and we can consider changing the default in a later
release f
Why not have some default templates that can be specified by the schema without
touching the yaml, but overridden in the yaml as necessary?
From: Branimir Lambov
Date: Wednesday, 9 February 2022 at 09:35
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-19: Trie memtable implementation
If
> Is there some mechanism such as experimental flags, which would allow the
> SAI-only OR support to be merged into trunk
FWIW, I’m OK with this merging to trunk, either hidden behind a CI-only flag or
exposed to the user via some experimental flag (and a suitable NEWS.txt). We’ve
discussed the
As discussed on 15234, there is never a rush to remove Config parameters, and
it should only be done when there’s some clear value. Since the overhead of
having an unused parameter is ~zero, in my opinion this occurs only when we
really need the operator to consider the semantic impact of its de
101 - 200 of 266 matches
Mail list logo
