Josh,
To say nothing is indifference. If you care about your community, sometimes
don't you have to bring up a subject even though you know it's also temporarily
adding some discomfort?
As to opening a JIRA, I've got a very specific topic to try in mind now. An
easy one I'll work on and then announce. Someone else will have to do the
coding. A year from now I would probably just knock it out to make sure it's
as easy as I expect it to be but to be honest, as I've been saying, I'm not set
up to do that right now. I've barely looked at any Cassandra code; for one;
everyone on this list probably codes more than I do, secondly; and lastly, it's
a good one for someone that wants an easy one to start with: vNodes. I've
already seen too many people seeking assistance with the vNode setting.
And you can expect as others have been mentioning that there should be similar
ones on compaction, repair and backup.
Microsoft knows poor usability gives them an easy market to take over. And they
make it easy to switch.
Beginning at 4:17 in the video, it says the following:
"You don't need to worry about replica sets, quorum or read repair.
You can focus on writing correct application logic."
At 4:42, it says:
"Hopefully this gives you a quick idea of how seamlessly you can bring
your existing Cassandra applications to Azure Cosmos DB. No code changes are
required. It works with your favorite Cassandra tools and drivers including
for example native Cassandra driver for Spark. And it takes seconds to get
going, and it's elastically and globally scalable."
More to come,
Kenneth Brotman
-----Original Message-----
From: Josh McKenzie [mailto:jmcken...@apache.org]
Sent: Wednesday, February 21, 2018 8:28 AM
To: d...@cassandra.apache.org
Cc: User
Subject: Re: Cassandra Needs to Grow Up by Version Five!
There's a disheartening amount of "here's where Cassandra is bad, and here's
what it needs to do for me for free" happening in this thread.
This is open-source software. Everyone is *strongly encouraged* to submit a
patch to move the needle on *any* of these things being complained about in
this thread.
For the Apache Way <https://www.apache.org/foundation/governance/> to work,
people need to step up and meaningfully contribute to a project to scratch
their own itch instead of just waiting for a random corporation-subsidized
engineer to happen to have interests that align with them and contribute that
to the project.
Beating a dead horse for things everyone on the project knows are serious pain
points is not productive.
On Wed, Feb 21, 2018 at 5:45 AM, Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> On Mon, Feb 19, 2018 at 10:01 AM, Kenneth Brotman <
> kenbrot...@yahoo.com.invalid> wrote:
>
> >
> > >> Cluster wide management should be a big theme in any next major
> release.
> > >>
> > >Na. Stability and testing should be a big theme in the next major
> release.
> > >
> >
> > Double Na on that one Jeff. I think you have a concern there about
> > the need to test sufficiently to ensure the stability of the next
> > major release. That makes perfect sense.- for every release,
> > especially the major ones. Continuous improvement is not a phase of
> > development for example. CI should be in everything, in every
> > phase. Stability and testing a part of every release not just one.
> > A major release should be
> a
> > nice step from the previous major release though.
> >
>
> I guess what Jeff refers to is the tick-tock release cycle experiment,
> which has proven to be a complete disaster by popular opinion.
>
> There's also the "materialized views" feature which failed to
> materialize in the end (pun intended) and had to be declared
> experimental retroactively.
>
> Another prominent example is incremental repair which was introduced
> as the default option in 2.2 and now is not recommended to use because
> of so many corner cases where it can fail. So again experimental as an
> afterthought.
>
> Not to mention that even if you are aware of the default incremental
> and go with full repair instead, you're still up for a sad surprise:
> anti-compaction will be triggered despite the "full" repair. Because
> anti-compaction is only disabled in case of sub-range repair (don't
> ask why), so you need to use something advanced like Reaper if you
> want to avoid that. I don't think you'll ever find this in the documentation.
>
> Honestly, for an eventually-consistent system like Cassandra
> anti-entropy repair is one of the most important pieces to get right.
> And Cassandra fails really badly on that one: the feature is not
> really well designed, poorly implemented and under-documented.
>
> In a summary, IMO, Cassandra is a poor implementation of some good ideas.
> It is a collection of hacks, not features. They sometimes play
> together accidentally, and rarely by design.
>
> Regards,
> --
> Alex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org
