Rs for
> each branch, that can be merged independently via the GitHub API. The
> downside of this is that there are no merge commits, while one upside of this
> is that there are no merge commits.
>
> On 18 Aug 2022, at 20:20, Stefan Miklosovic
> wrote:
>
> No chick
No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
commits. How would new merging strategy actually look like? I am all
ears. This seems to be quite nice as is if we stick to be more verbose
what we did.
On Thu, 18 Aug 2022 at 20:27, Benedict wrote:
>
> Was it?
>
> I mean,
I will gladly apply commit messages to merge commits as well from now
on (or when we formally vote on that, if you prefer).
On Thu, 18 Aug 2022 at 18:21, Mick Semb Wever wrote:
>
>
>> There's `git merge --log` which provides a short-form log in the merge
>> commit.
>
>
>
> Let's do it!
>
> Can
y to incorporate into the workflow?
>
> The hard part isn't incorporating this into one's workflow, the hard part is
> getting all of us to agree that this is something we should all do and
> formalize it as our project process. :)
>
> On Thu, Aug 18, 2022, at 10:41 AM, Stefan Miklosovic
s into one's workflow, the hard part is
> getting all of us to agree that this is something we should all do and
> formalize it as our project process. :)
>
> On Thu, Aug 18, 2022, at 10:41 AM, Stefan Miklosovic wrote:
>
> Adding commit messages into merge commits for increased unders
Adding commit messages into merge commits for increased understanding
of the codebase when you are git-blaming is the absolute minimum we
can do to help you with (not only) your frustration. merging with -s
ours opens up an editor where you do have a possibility to tweak the
message as you wish so
I like auto linking, definitely a handy feature.
I am not sure about the content of the pull request description. I
would include what that PR is actually for / why it is necessary to
merge it and into what branches a contributor expects that PR to be
merged in. However, this might be omitted if
https://lists.apache.org/thread/mkskwxn921t5bkfmnog032qvnyjk82t7
On Fri, 3 Jun 2022 at 16:11, Derek Chen-Becker wrote:
>
> I think we discussed this a couple of weeks ago, but to reiterate my
> position: I think we should use annotations where they allow the compiler and
> ancillary tooling
Hi,
I was living with the fact that we are putting @Override in the cases
you described already. I _think_ it was David Capwell (sorry if I am
wrong here) who suggested we should start to put @Override on these
methods but it was a very long time ago. I'll try to go over the ML
archive to find
Hi Benedict, all,
I do not want to hijack this thread, if we want to have separate
discussion about that I can open one but anyway ...
What do you think about Javadocs? I do not see that it is mentioned
but Javadocs are technically the code as well (well, they are written
in the source code,
Hi Mick,
I do not mind having alpha1 out. It will help me with setting up all
build pipelines for our plugins / tools / libraries as now I can not
build it as snapshot is not released anywhere nor I can depend on it
in Maven projects, for example.
So yeah, +1 from me.
Regards
On Wed, 18 May
+1
On Sat, 7 May 2022 at 08:39, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.11.13 for release.
>
> sha1: 836ab2802521a685efe84382cb48db56caf4478d
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative
> Maven Artifacts:
>
> DatabaseDescriptor.toolInitialization() ?
>
> 2) In your code, keyspace metadata (table metadata and column metadata) is
> not constructed and loaded into the Schema instance.
> You are using Schema.instance.loadFromDisk(false)
> Is this the preferred way to load the s
Hi Sanal,
I have recently updated a project called Debezium and its Cassandra
connector to work with Cassandra 4 (1)
The implementation of CommitLogReadHandler is here (2)
(1) https://github.com/debezium/debezium-connector-cassandra
(2)
I will revert it as I committed it, before the freeze.
I have to admit these points you have are all valid, this seems to be
harder than one might think. In this light, as it stands now, it is a
pretty much half-cooked solution doing potentially more harm than
good. The user had a request that
16456 is crucial for me to get in. We are at the end. Should be all
resolved by end of this week.
On Mon, 25 Apr 2022 at 18:33, Paulo Motta wrote:
>
> Hi Ekaterina,
>
> Thanks for bringing this up.
>
> I'm hoping to complete the following tickets before the freeze before May 1st:
>
> -
I have checked with Ekaterina, we are ok with what she asked us to
take a look at. Other than that, I do not remember I have touched /
worked with any other mentioned parameter she elaborated on between
4.0 and 4.1 so I can not comment on that.
On Tue, 5 Apr 2022 at 23:24, Ekaterina Dimitrova
But ... this begs another question to be asked - until when we want to
support Centos 7 ?
On Tue, 5 Apr 2022 at 13:31, Stefan Miklosovic
wrote:
>
> All good then, that's why I am asking!
>
> Thanks
>
> On Tue, 5 Apr 2022 at 13:23, Brandon Williams wrote:
> >
> > Th
ot maintained by the same project or compile it from
> > source. None of these is as simple as "yum install epel-release && yum
> > install python36".
> >
> > I would strongly recommend keeping Python 3.6 compatibility until
> > 2024-06-30 when the CentOS 7 main
hing lower.
https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L38-L39
On Tue, 5 Apr 2022 at 12:35, Stefan Miklosovic
wrote:
>
> Hello,
>
> I stumbled upon this ticket (1)
>
> We will have Cassandra running with unsupported Python 3.6 once we
> release 4.1 which is no
Hello,
I stumbled upon this ticket (1)
We will have Cassandra running with unsupported Python 3.6 once we
release 4.1 which is not good in my books.
I would like to try to bump it to 3.8 as minimum, it will get security
updates to 2024 at least.
Does it make sense to people? Especially so
0 Mar 2022 at 16:56, Stefan Miklosovic
wrote:
>
> Why not N guys instead of two? Where does this stop? "2" seems to be
> an arbitrary number. This starts to remind me of Shamir's shared
> secrets.
>
> https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
>
> On We
Why not N guys instead of two? Where does this stop? "2" seems to be
an arbitrary number. This starts to remind me of Shamir's shared
secrets.
https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
On Wed, 30 Mar 2022 at 16:36, Tibor Répási wrote:
>
> … TWO_MAN_RULE could probably be poor
Hi,
We are implementing a feature which relies on the fact that the
executor for periodic tasks is shut down on drain which is not
happening now (o.a.c.concurrent.ScheduledExecutors.scheduledTasks).
I want to ask if there is some reason we are not shutting down all
executors in
Hi Tibor,
Thanks for raising this.
Do you see some important issues you would like to address by
switching to a newer Airline or are we updating just because the
former version is not supported anymore? How much do you miss the new
Airline library and does the older library prevent you from
So, I went through all pull requests we have on GitHub manually (yes,
I did that, never more!) and out of ~550 PRs I managed to reduce it to
188 so I closed around 400 PRs.
All remaining PRs are of this nature:
1) Every PR has a name of "CASSANDRA-XYZ - description" or there is a
ticket number
ated tickets), I don't ever work on them. I'll aim to do this when I
> have bandwidth. Cheers!
>
> On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic
> wrote:
>>
>> Hello,
>>
>> Is somebody fundamentally opposing the idea of applying labels to pull
>
Hello,
Is somebody fundamentally opposing the idea of applying labels to pull
requests when applicable? I went through the pull requests and it
would be nice to have some basic filters, like "show me all pull
requests related to documentation" would be labeled as "docs", then
PRs fixing some
I agree with the single commit approach to fix it all. TBH Javadocs
are a little bit messy as well, warnings on generating them,
incomplete, in a lot of cases obsolete or they do not reflect the code
anymore etc.
On Tue, 15 Mar 2022 at 09:44, bened...@apache.org wrote:
>
> I’d be fine with that,
I agree on not using finals as suggested by Marcus, I have been using
them where I could, sometimes for the sake of having them final to be
consistent with other code but I gladly drop this habit. Too bad Java
doesnt have it like Scala where it is the matter of "var" vs "val".
On Mon, 14 Mar 2022
Hi Bowen,
we were working on that recently, like CASSANDRA-17413 + a lot of
improvements around Python stuff are coming. If you identify more
places for improvements we are definitely interested.
Regards
On Mon, 14 Mar 2022 at 11:53, Bowen Song wrote:
>
> I found there's no mentioning of
sible, how are we going to treat this in dtests
when we will have stuff for 3.11, 4 on old configs and 5 on new
configs?
On Tue, 22 Feb 2022 at 21:48, Stefan Miklosovic
wrote:
>
> +1 to what Patrick says.
>
> On Tue, 22 Feb 2022 at 21:40, Patrick McFadin wrote:
> >
> > I'm go
+1 to what Patrick says.
On Tue, 22 Feb 2022 at 21:40, Patrick McFadin wrote:
>
> I'm going to put up a red flag of making config file changes of this scale on
> a dot release. This should really be a 5.0 consideration.
>
> With that, I would propose a #5. 5.0 nodes will only read the new
Benjamin's email could be written by myself :) Fully agree.
On Fri, 18 Feb 2022 at 09:42, Benjamin Lerer wrote:
>
> Thanks a lot for raising that topic Alex.
>
> I did not have the chance to use Harry yet and I guess it is the case for
> most of us.
> Starting to use it in our new tests makes
I think that it is not only about the build tool as such. There is a
lot of scripting involved in build scripts as well as in Jenkins
pipeline and so on. I am not sure how to make a transition like this,
testing it all while people are developing at the same time. Some
problems like
Hi,
scripts for Windows support for Cassandra were dropped in 4.0.0 (as
well as in beta4) as part of (1). The thing is that this work was not
done fully because the code itself (Java sources) were not modified
and they still contained a lot of Windows-specific logic.
Hence, we are removing that
Does somebody else use the git workflow we do as of now in Apache
universe? Are not we quite unique? While I do share the same opinion
Mick has in his last response, I also see the disadvantage in having
the commit history polluted by merges. I am genuinely curious if there
is any other Apache
Hi,
FYI I am planning to put together all we discussed under sstable
encryption thread into a kind-of CEP to distil everything said. I hope
I'll put it together in the foreseeable future before taking a longer
break till February. I am not sure if that is enough time to implement
it if we
On Fri, 19 Nov 2021 at 03:03, Joseph Lynch wrote:
>
> >
> > I've seen this be a significant obstacle for people who want to adopt
> > Apache Cassandra many times and an insurmountable obstacle on multiple
> > occasions. From what I've seen, I think this is one of the most watched
> > tickets with
On Fri, 19 Nov 2021 at 02:51, Joseph Lynch wrote:
>
> On Thu, Nov 18, 2021 at 7:23 PM Kokoori, Shylaja
> wrote:
>
> > To address Joey's concern, the OpenJDK JVM and its derivatives optimize
> > Java crypto based on the underlying HW capabilities. For example, if the
> > underlying HW supports
sink cycles into.
>
> -Joey
>
> On Tue, Nov 16, 2021 at 7:01 AM Stefan Miklosovic
> wrote:
> >
> > I don't object to having the discussion about whether we actually need
> > this feature at all :)
> >
> > Let's hear from people in the fiel
://github.com/FiloSottile/age
>
> -Joey
>
>
> On Sat, Nov 13, 2021 at 6:01 AM Stefan Miklosovic
> wrote:
> >
> > Hi list,
> >
> > an engineer from Intel - Shylaja Kokoori (who is watching this list
> > closely) has retrofitted the original code from C
the source node. The receiving
> side will then need to unwrap Kr with the KEK and re-wrap it with a new
> KEK' derived from their own GEN. GEN is not considered as a secret.
>
>
> On 16/11/2021 12:13, Stefan Miklosovic wrote:
> > Thanks for the insights of everybody.
> >
>
d some authentication of the
> > recipient node before streaming the file as it would effectively be
> > decrypted to any node that could request this streaming action.
> >
> >
> > From: Stefan Miklosovic
> > Date: Tuesday, 16 November 2021 at 10:45
>
key derived from) a user chosen key.
>
> If this approach is adopted, the streaming process can share the Kr
> without disclosing the Km, therefore enableling zero-copy streaming.
>
> On 16/11/2021 08:56, Stefan Miklosovic wrote:
> > Hi Bowen, Very interesting idea indeed. So if I
, Stefan Miklosovic
wrote:
>
> Hi Bowen, Very interesting idea indeed. So if I got it right, the very
> key for the actual sstable encryption would be always the same, it is
> just what is wrapped would differ. So if we rotate, we basically only
> change Km hence KEK hence the res
> the encryption info file
>
> Since the key rotation only involves rewriting the encryption info file,
> the operation should take only a few milliseconds per SSTable file, it
> will be much faster than decrypting and then re-encrypting the SSTable data.
>
>
>
> On 15/11
On Mon, 15 Nov 2021 at 19:42, Jeremiah D Jordan
wrote:
>
>
>
> > On Nov 14, 2021, at 3:53 PM, Stefan Miklosovic
> > wrote:
> >
> > Hey,
> >
> > there are two points we are not completely sure about.
> >
> > The first one is streaming. If
t; On Nov 13, 2021, at 7:53 AM, Brandon Williams wrote:
> >
> > We already have a ticket and this predated CEPs, and being an
> > obviously good improvement to have that many have been asking for for
> > some time now, I don't see the need for a CEP here.
> >
>
Hi list,
an engineer from Intel - Shylaja Kokoori (who is watching this list
closely) has retrofitted the original code from CASSANDRA-9633 work in
times of 3.4 to the current trunk with my help here and there, mostly
cosmetic.
I would like to know if there is a general consensus about me going
sign me up
On Fri, 12 Nov 2021 at 18:16, Brandon Williams wrote:
>
> I'm interested.
>
> On Fri, Nov 12, 2021 at 11:05 AM Benjamin Lerer wrote:
> >
> > Hi everybody
> >
> > As discussed in the *Creating a new slack channel for newcomers* thead, a
> > solution to help newcomers engage with the
l column that is
> updated periodically (ie. every minute) + on drain? This would give a lower
> time bound on when the node was last live without requiring an external
> marker file.
>
> On Wed, 3 Nov 2021 at 18:03 Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
&
not right ...
On Wed, 3 Nov 2021 at 21:53, Stefan Miklosovic
wrote:
>
> Hi,
>
> We see a lot of cases out there when a node was down for longer than
> the GC period and once that node is up there are a lot of zombie data
> issues ... you know the story.
>
> We would like to im
Hi,
We see a lot of cases out there when a node was down for longer than
the GC period and once that node is up there are a lot of zombie data
issues ... you know the story.
We would like to implement some kind of a check which would detect
this so that node would not start in the first place so
I am all for good extensibility / interfaces and so on, however I am
afraid that this might actually break a lot of things if enough
attention is not paid. For example, over all these years, the
community around Cassandra tooling is somehow used to the "mess",
placing one fat jar to the class path
t
will use SSTableReader / Writer stuff so I think that the modification
of these classes to accommodate this idea would be necessary.
On Fri, 22 Oct 2021 at 11:02, Stefan Miklosovic
wrote:
>
> Hi Jacek,
>
> Thanks for taking the lead on this.
>
> There was importing of SSTables introduced
Hi Jacek,
Thanks for taking the lead on this.
There was importing of SSTables introduced in 4.0 via
StorageService#importNewSSTables. The "problem" with this is that
SSTables need to be physically located at disk so Cassandra can read
them. If a backup is taken and SSTables are uploaded to, for
Hi Ekaterina, all,
If you eventually decide to switch it to automatic build on push (I
like how it is now though), I would appreciate it if there was some
option in generation scripts (generate.sh) so I could just have some
shortcut / alias which would disable this very easily.
It would be very
1. +1
2. +1 nb
3. +1 nb
nb on 2. and 3. as I am not pmc (if I got this voting logic right)
On Thu, 14 Oct 2021 at 18:36, Blake Eggleston
wrote:
>
> 1. +1
> 2. +1
> 3. +1
>
> > On Oct 14, 2021, at 9:31 AM, bened...@apache.org wrote:
> >
> > Hi everyone,
> >
> > I would like to start a vote on
The vote passed with 6 binding +1's and no -1's
Thanks everybody.
On Mon, 11 Oct 2021 at 23:34, Michael Shuler wrote:
>
> +1
>
> On 10/11/21 4:47 AM, Stefan Miklosovic wrote:
> > Hi list,
> >
> > based on the discussion thread about CEP-16 (1), I
ould be very nice but I do not know
> > if that makes sense from your point of view (what workflow you have).”
> >
> > It is up to us to decide what would be the most efficient way how to move
> > forward as a community so any ideas are appreciated. I think Anthony had
>
I agree with Benedict, this does not need to have its own CEP.
In the "approach" section to-be-discussed CEP-17, I clearly see this
is building on top of what is already in so I do not think this needs
yet another CEP to materialize.
Regards
On Mon, 11 Oct 2021 at 12:00, bened...@apache.org
Hi list,
based on the discussion thread about CEP-16 (1), I would like to have
a vote on that.
It seems to me CEP-16 is so straightforward there is more or less
nothing to discuss in more depth as the feedback it gathered was
mostly formal and nobody has had any objections so far having the
Hi Lorina, Ekaterina,
In general your approach sounds good to me. I am also +1 on not
creating too many tickets as I can see it will be easy to get lost in.
If it was feasible to gather all related changes touching a subsystem
under one umbrella ticket, that would be very nice but I do not know
Lerer wrote:
>
> +1
>
> Le mar. 21 sept. 2021 à 18:17, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> a écrit :
>
> > Hi Brian,
> >
> > feel free to proceed and create CEP in Confluence and we might vote on
> > that afterwards.
> >
>
Hi Benedict,
do I need to somehow accommodate this initiative in such a way that I
will postpone what I have (like CEP-9 is pretty close to merging) so
you have it easier to merge that? It seems to me these patches are
quite big and I am just thinking how to make it easier for you -
without
Hi Brian,
feel free to proceed and create CEP in Confluence and we might vote on
that afterwards.
Regards
On Thu, 16 Sept 2021 at 23:04, bhouse99 wrote:
>
> Heya everyone! I just wanted to mention that Stefan Miklosovic and I are
> planning on moving the following as a formal CEP to
Hi Mick,
I returned to this after some time and here are my questions about this.
I am waiting for 16806 to be merged which introduces abstract mutable
vtables (1) on top of which I want to build what you have proposed.
I do not think we need a non-virtual table for this and this is
actually
+1
On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>
> Candidate SHA:
>
.
Regards
On Tue, 17 Aug 2021 at 17:13, Stefan Miklosovic
wrote:
>
> Hi Jack,
>
> we are already working on this under (1), the branch is here (2)
>
> This improvement is done under Google Summer of Code programme where
> Abi Palagashvili is assigned to it already.
>
> We
Hi Jack,
we are already working on this under (1), the branch is here (2)
This improvement is done under Google Summer of Code programme where
Abi Palagashvili is assigned to it already.
We are about to finish this feature more or less this week.
Would you mind going over this work and raising
Super exciting, congratulations everybody. Great times ahead!
On Mon, 26 Jul 2021 at 22:19, Patrick McFadin wrote:
>
> Wow. Just wow. Congratulations to everyone involved in this huge milestone.
>
> On Mon, Jul 26, 2021 at 1:04 PM Brandon Williams wrote:
>
> > The Cassandra team is pleased to
Yes, limits are good, in case of a solution for virtual tables. I can
imagine that it will be use just for the sake of diagnostics what a
node is doing and so on and even we lift the limit to something like
1000, that is already a plenty to show a respective operator (as a
person) what a node does
ty.apache.org/committers/lazyConsensus.html>, so as long as
> > nobody opposes your proposal you're good to move forward with it, so people
> > not caring to even dropping an e-mail can actually be a good thing. ;)
> >
> > Em qua., 21 de jul. de 2021 às 03:39, Stefan
Hi,
should I create CEP first or people just absolutely do not care to
even drop an email and it does not make sense to them?
Regards
On Mon, 19 Jul 2021 at 15:32, Stefan Miklosovic
wrote:
>
> Hi,
>
> I wonder if people would be interested in having diagnostic events in
> virtua
Hi,
I wonder if people would be interested in having diagnostic events in
virtual tables?
I put something together here (heavy wip) (1) but that is the idea I have.
I know that Stefan Podkowinski did a spectacular job under
CASSANDRA-12944 and the possibility to persist locally was elaborated
asonable and valid.
>
>
> On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan
> wrote:
>
> > I see no problem with continuing to add JMX commands for the foreseeable
> > future.
> >
> > > On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic <
> > stefan.mikloso...@inst
Can I have a clear response from you, community, if my work on 16725
is rendered totally useless in the light of this discussion? The time
on that was already spent and I honestly can not see why it would be a
problem to merge that command in.
I am particularly objecting to Paulo's idea about
Hi Benjamin,
I was discussing this closely with Paulo some time ago, you may have
already read the other email about this topic when I was talking about
what we wanted to do with a GSOC student. I just can not find it for
now ...
In general I agree that we might slowly drift away from nodetool
Hi,
ok, so this will make it to 4.0 then.
I would re-iterate on FQL logging though. What is our decision? Should
these passwords be clearly visible or we should obfuscate them too?
I am trying to close all remaining questions, while I do get that
passwords in audit are for sure problematic, I
Hi list,
During our evaluation of 4.0 internally, we noticed that there are
passwords in the plaintext in audit logging (and in fql). While I was
going through CASSANDRA-12151, I noticed that the password obfuscation
in these components was planned but it was never implemented and it
was merged
Congratulations Dinesh!
On Wed, 2 Jun 2021 at 19:55, Joshua McKenzie wrote:
>
> Congrats Dinesh!
>
> On Wed, Jun 2, 2021 at 12:52 PM Scott Andreas wrote:
>
> > Congratulations, Dinesh!
> >
> >
> > From: Lorina Poland
> > Sent: Wednesday, June 2, 2021
Quake has it like
- I Can Win
- Bring It On
- Hurt Me Plenty
- Hardcore
- Nightmare!
On Tue, 27 Apr 2021 at 19:02, Benedict Elliott Smith
wrote:
>
> I think Duke Nuke'em would be more apt
>
> - Piece of Cake
> - Let's Rock
> - Come Get Some
> - Damn I'm Good
>
> On 27/04/2021, 17:57, "Patrick
contributors
might go directly to the right person.
On the other hand it is not too good if there is a lot of knowledge of
some subsystem in the hands of few people only, but I still think that
might be valuable to do anyway.
On Tue, 27 Apr 2021 at 14:47, Stefan Miklosovic
wrote:
>
> On T
; incentives for people to stick around for a few tickets.
>
> On 27/04/2021, 13:22, "Stefan Miklosovic"
> wrote:
>
> It really boils down just to a simple "problem" to have enough
> committers to look at it over a (preferably) shorter period of time
>
It really boils down just to a simple "problem" to have enough
committers to look at it over a (preferably) shorter period of time
and make that feedback loop shorter. That's it. You might have the
best guides and whatever but if a dust settles at it no guide will
make it happen.
On Tue, 27 Apr
Hi,
is this version of the web page already "analytics friendly"? In the
context of https://plausible.cassandra.apache.org/cassandra.apache.org
On Sun, 25 Apr 2021 at 13:44, Michael Semb Wever wrote:
>
>
> > As a risk mitigator, I was hoping we could preserve
> > the sub-URIs so the switch
Hi,
for me definitely https://issues.apache.org/jira/browse/CASSANDRA-9633
I am surprised nobody mentioned this in the previous answers, there is
~50 people waiting for it to happen and multiple people working on it
seriously and wanting that feature to be there for so so long.
We will come up
Hi Mick,
it is here https://issues.apache.org/jira/browse/CASSANDRA-16597
On Tue, 13 Apr 2021 at 13:24, Michael Semb Wever wrote:
>
>
>
> > Actually, I am not completely sure if Maven wrapper will play nicely
> > with Ant stuff of yours as maybe it indeed looks for "mvn" on path and
> > wrapper
Actually, I am not completely sure if Maven wrapper will play nicely
with Ant stuff of yours as maybe it indeed looks for "mvn" on path and
wrapper is invoked differently so it does not have to necessarily see
it. I ll check it and let you know.
Regards
On Mon, 5 Apr 2021 at 17:
Superb stuff, thanks Mick.
Would it maybe be possible to include some automatic way to get Maven?
Maven wrapper is the standard here I would say, it is possible to do
it such a way that JAR does not need to be included either.
I can prepare PR with this.
Hi Paulo,
it might seem as me complaining but that is not the case here so just
hear me out please.
I think that the primary reason for tickets not being resolved / they
are abandoned / they are not worked on anymore is not the fact that
they are just "forgotten" but I believe that it is also
Hi all,
I have managed to deploy an instance of Plausible (1) service for the
upcoming, brand new Cassandra web page (2 and 3).
Please keep in mind that the current figures for staging web were
aggregated just during our testing just to see how it all actually
works, the integration for
Looks great, congrats!
On Fri, 26 Feb 2021 at 22:36, Melissa Logan wrote:
>
> Hi all,
>
> We are excited to share the almost-complete Cassandra website design
> (CASSANDRA-16115). Huge thanks to Lorina Poland, Anthony Grosso, Mick Semb
> Weaver, Josh Levy, Chris Thornett, Diogenese Topper, and a
Hi Lorina,
we at Instaclustr are supporting that Lucene plugin for Cassandra 3
and we work towards Cassandra 4 support too.
I suggest you proceed with the removal of that plugin page and later
down the road I will add it to tooling page as Michael sent it.
How does that sound?
Regards
On Thu,
Hi Paolo,
I have been working on some CEP (not sure if the change is so big it
requires one but whatever) to provide a pluggable system to cqlsh for
various authentication providers. Right now they are in a Python
driver but a user can not choose which one to use, not even mentioning
anything
I checked and cassandra channel was created by zznate at apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
my world (relational), perf can be improved by
> spreading queries out to different databases. I saw a presentation where a
> Cassandra keyspace was said to be roughly equivalent to a relational database.
>
> -Original Message-
> From: Stefan Miklosovic
> Sent: Tuesday
hat "dev" means working on Cassandra
> itself. Sorry about that. I'll move the conversation to user@
>
> Thanks very much all for your contributions.
>
>
> -Original Message-
> From: Stefan Miklosovic
> Sent: Tuesday, December 15, 2020 12:59 PM
> To: de
Hi,
why can't this be achieved by batches? Do I miss something fundamental
here? Batches may write to different tables right ... I am just
missing the point of using triggers for this.
I add specifics to Brian's first paragraph, this is covered by
CASSANDRA-13985 -
1 - 100 of 124 matches
Mail list logo
