> > Any insights would be helpful.
> > Thanks!
> > Sagar.
> > On Sat, Mar 2, 2019 at 7:23 AM Jonathan Haddad
> > > Instead of logging to tables, putting a virtual table around the audit
> > > query logs
; of Zstd compression levels.
> > On Mar 1, 2019, at 6:41 PM, Jonathan Haddad wrote:
> > Hey all,
> > I finally got around to doing some testing. Nothing too crazy, I had it
> > run on my laptop while I did other things around the
I finally got around to doing some testing. Nothing too crazy, I had it
run on my laptop while I did other things around the house.
Test 1: Inserting Random Data in a K/V table, 10 million inserts
LZ4 compression rate: 0.909857609644112
Test 2: Inserting
ose, side-channel file storage
> > >> format for transient things like this (hints, batches, audit logs,
> > >> could be useful as a first class citizen in the codebase? i.e. a world
> > in
> > >> which we refactored some of the hints-specific reader/
Agreed with Dinesh and Josh. I would *never* put the audit log back in
This is extendable, Sagar, so you're free to do as you want, but I'm very
opposed to putting a ticking time bomb in Cassandra proper.
On Thu, Feb 28, 2019 at 8:38 AM Dinesh Joshi
> I strongly echo
Seems low risk, potentially high reward.
I can run some tests next week to get a rough idea of how compression
ratios differ as well as if there's a difference in performance.
I won't be testing correctness, just looking at the performance profile.
On Fri, Feb 15, 2019 at 9:56 AM Michael
I think having the discussion around EOL is pretty important, in order to
set the right expectations for the community.
Looking at the commits for 2.1, there's hardly any activity going on,
meaning it's effectively been EOL'ed for a long time now. I think it's
better that we be honest with folks
On Sun, Feb 3, 2019 at 9:35 AM Nate McCall wrote:
> On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler
> > I propose the following artifacts for release as 3.11.4.
> > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> > Git:
On Sun, Feb 3, 2019 at 9:44 AM Nate McCall wrote:
> On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler
> > I propose the following artifacts for release as 3.0.18.
> > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> > Git:
In addition to what Jeff mentioned, there was an optimization in 3.4 that
can significantly reduce the number of sstables accessed when a LIMIT
clause was used. This can be a pretty big win with TWCS.
I'm +1 on the warning for two reasons.
> A cqlsh warning only applies to those that create the sasi via cqlsh.
1. When people are creating their schemas in development, this is usually
the first step. You use the REPL to figure out what you need, then you
copy your schema somewhere else. The
Ping on this.
On Mon, Jan 7, 2019 at 5:58 PM Michael Shuler
> No problem, thanks for asking :)
> On 1/7/19 6:20 PM, Jonathan Haddad wrote:
> > It's been 5 months and 30+ bug fixes to each branch.
> > Here's the two changelogs:
I'm very much in favor of a warning, and I lean towards disabling them (and
MVs, while we're at it) by default as well.
I've seen both features be the death of clusters, and are a major risk for
teams that are brand new to Cassandra.
On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña
It's been 5 months and 30+ bug fixes to each branch.
Here's the two changelogs:
How's everyone feel about getting a release out this week / early next
changes, users need to modify their trust
> on every node, importing new key(s), in order for packages to
> install/upgrade with apt or yum.
> I don't understand how adding keys changes release frequency. Did
> someone request a release to be made or are we on some assumed date
That's a good point. Looking at the ASF docs I had assumed the release
manager was per-project, but on closer inspection it appears to be
per-release. You're right, it does say that it can be any committer.
We definitely need
I agree with Stefan, if someone isn't a release manager there's no reason
to add them, and it just increases the surface area for potential attack or
On Mon, Jan 7, 2019 at 11:35 AM Stefan Podkowinski wrote:
> I don't see any reason to have any keys in there, except from release
the above cassandra-builds commit.
> - https://builds.apache.org/job/Cassandra-Job-DSL/
> The only other consideration I can think of after migration is checking
> the git.a.o bare and github mirror post-commit hooks work as expected.
> - http://git.apache.org/cassandra.git/
Silence can be interpreted either as non-awareness or implicit approval.
I interpreted (and meant) +1 as "go for it now".
On Fri, Jan 4, 2019 at 8:48 AM Sam Tunnicliffe wrote:
> Yeah, I wasn’t really proposing a vote as like you said, it’s happening
> anyway. I was just going to give a few
On Fri, Jan 4, 2019 at 8:13 AM Ariel Weisberg wrote:
> On Fri, Jan 4, 2019, at 5:49 AM, Sam Tunnicliffe wrote:
> > As per the announcement on 7th December 2018, ASF infra are planning
> > to shutdown the service behind git-wip-us.apache.org and migrate all
> > existing repos to
On Mon, Dec 17, 2018 at 9:50 AM Blake Eggleston
> > On Dec 17, 2018, at 9:31 AM, jay.zhu...@yahoo.com.INVALID wrote:
> > +1
> >On Monday, December 17, 2018, 9:10:55 AM PST, Jason Brown <
> jasedbr...@gmail.com> wrote:
> > +1.
> > On Mon, Dec 17, 2018 at 7:36
My personal preference is to remove labels, but I don't see it as a huge
issue if they stay.
2. prefer to remove (I suppose I'm a -.1?)
5. No preference
On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID
> 1: Component. (A) Multi-select
> 2: Labels:
> > Sylvain
> >> I will make this more explicit for the vote, but just to clarify the
> >> intention so that we are all discussing the same thing.
> >>> On 20 Nov 2018, at 14:18, Ariel Weisberg wrote:
If nobody has any objections to CASSANDRA-14303 (default RF) being merged
in I can take care of it. It's a significant usability improvement, looks
well tested and will prevent a number of headaches.
I'll try to get to it tomorrow.
Thanks for bringing these up, Vinay.
On Tue, Nov 20, 2018
On Mon, Nov 19, 2018 at 1:02 PM Steinmaurer, Thomas <
> am I right that Java 11 support will only be in Cassandra 4.0 and not in
> future releases of the 3.11.x series? Just want to be sure.
> The contents of
Sounds good to me.
On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith
> So, this thread somewhat petered out.
> There are still a number of unresolved issues, but to make progress I
> wonder if it would first be helpful to have a vote on ensuring we are ANSI
> SQL 92 compliant for
> > -0:
> > Sylvaine Lebresne
> > -.5:
> > Jeff Jirsa
> > This
> > (
> > is a rough cut of the change for the representat
and we never were really explicit that those sort of optimizations would be
excluded after our feature freeze. I don't think they should necessarily
be excluded at this time, but it depends on the size and risk of the patch.
On Sat, Oct 20, 2018 at 8:38 AM Jonathan Haddad wrote:
> I think we sho
I think we should try to do the right thing for the most people that we
can. The number of folks impacted by 64KB is huge. I've worked on a lot
of clusters created by a lot of different teams, going from brand new to
pretty damn knowledgeable. I can't think of a single time over the last 2
Recently I reached an inflection point where my annoyance of launching
clusters finally overcame my laziness. I wanted something similar to CCM,
so I wrote it.
The tool was designed for our usage at TLP, which usually means quickly
firing up clusters for running tests. It started out as some
Thanks for bringing this up, it definitely needs to be discussed.
Last surprise is difficult here, since all major databases have their own
way of doing things and people will just assume that their way is the right
way. On that note, some people will be surprised no matter what we do.
have created CASSANDRA-14784 to track this.
> > >
> > > Dinesh
> > >
> > >> On Sep 21, 2018, at 9:18 PM, Sankalp Kohli
> > wrote:
> > >>
> > >> Putting it on JIRA is to make sure someone is assigned to it and it is
> > tr
> > > On Sep 21, 2018, at 8:24 PM, Jeremy Hanna
> > wrote:
> > >
> > > I agree that it should be lowered. What I’ve seen debated a bit in the
> > past is the number but I don’t think anyone thinks that it should remain
> > 256.
One thing that's really, really bothered me for a while is how we default
to 256 tokens still. There's no experienced operator that leaves it as is
at this point, meaning the only people using 256 are the poor folks that
just got started using C*. I've worked with over a hundred clusters in the
Sure - I'm not disagreeing with you that pre-built packages would be nice
to have. That said, if someone's gone through the trouble of building an
entire testing infrastructure and has hundreds of machines available,
running `docker-compose up build-deb` is likely not a major issue. If I'm
It seems to me that improving / simplifying the process of building the
packages might solve this problem better. For example, in the tests you
linked to, they were using a custom build that hadn't been rolled into
trunk. I expect we're going to see a lot of that.
If we make building a deb
at was addressed by Jeff Jirsa and
> deserves a separate thread as it is not directly related to this thread.
> 3. Does the project need a side car.
> From Jonathan Haddad
> 4. Are people doing +1 willing to contribute
> From Jonathan Ellis
> 5. List of feature set, m
This voting process feels a bit rushed and frankly not well thought out.
In addition to Sylvain's valid points, which you (Sankalp) didn't address
at all, the discussion in the other threads seemed to be ongoing. The last
email you wrote on one of them was asking for additional feedback, that
I'm +0, and I share the same concerns as Sylvain.
For those of you that have +1'ed, are you planning on contributing to the
driver? Docs, code, QA? It's easy to throw a +1 down to make the driver
the responsibility of the project if you're asking others to do the work.
I vote this way because I
It's interesting to me that someone would consider features of Reaper as
"technical debt"... an odd way to word it. When we had proposed donating
Reaper to the project, I had made the assumption people would realize the
benefit of folding in a successful project. A working codebase with a
We haven’t even defined any requirements for an admin tool. It’s hard to
make a case for anything without agreement on what we’re trying to build.
On Fri, Sep 7, 2018 at 7:17 PM Jeff Jirsa wrote:
> How can we continue moving this forward?
> Mick/Jon/TLP folks, is there a path here where we
Test plans and results could be posted to said
> JIRAs, to be closed once a given test passes. Any bugs found can also then
> be related back to such a ticket for tracking them as well.
> > On Sep 6, 2018, at 12:27 PM, Jonathan Haddad wrote:
oks like most testing is done by doing
> an operation or running a load and seeing if it "worked" and no errors in
> Another important thing will be to fix bugs asap ahead of testing, as
> fixes can lead to more bugs :)
> On Thu, Sep 6, 2018 at 7:52 AM Jonat
On Thu, Sep 6, 2018 at 10:35 AM Jordan West wrote:
> Thanks for staring this thread Jon!
> On Thu, Sep 6, 2018 at 5:51 AM Jonathan Haddad wrote:
> > For 4.0, I'm thinking it would be a good idea to put together a list of
> > things that need testing an
For 4.0, I'm thinking it would be a good idea to put together a list of the
things that need testing and see if people are willing to help test / break
those things. My goal here is to get as much coverage as possible, and let
folks focus on really hammering on specific things rather than just
> > also be able to provide space in bay area and help to organize it.
> > let us know, so we could get final approval for that).
> > On Fri, Jul 27, 2018 at 10:05 AM Jonathan Haddad
> > wrote:
> > > My interpretatio
Definitely does not belong in the same repo.
I’m all for folding drivers in / writing our own, just needs active
On Fri, Aug 31, 2018 at 7:45 AM Michael Shuler
> On 08/31/2018 09:34 AM, Jay Zhuang wrote:
> > That's great. Could that be in the same repo as Cassandra or a
Advertised, yes, but so far I haven't found it to be any better than
ParNew + CMS or G1 in the performance tests I did when writing
That said, I didn't try it with a huge heap (i think it was 16 or 24GB), so
maybe it'll do better if I throw 50
I'm also very interested.
On Tue, Aug 28, 2018 at 8:47 AM Dinesh Joshi
> > On Aug 28, 2018, at 6:33 AM, Marcus Olsson
> > Hi,
> > With the risk of stirring the repair/side-car topic even further I'd
> just like to mention that we have recently gotten approval to
finishing up the rework of the code to run it as a sidecar.
On Mon, Aug 27, 2018 at 6:02 PM Jeff Jirsa wrote:
> Can you get all of the contributors cleared?
> What’s the architecture? Is it centralized? Is there a sidecar?
> > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad wrote:
Mick brought this up in the sidecar thread, but I wanted to have a clear /
separate discussion about what we're thinking with regard to contributing
Reaper to the C* project. In my mind, starting with Reaper is a great way
of having an admin right now, that we know works well at the
Strongly agree with Blake. In my mind supporting multiple versions is
mandatory. As I've stated before, we already do it with Reaper, I'd
consider it a major misstep if we couldn't support multiple with the
project - provided admin tool. It's the same reason dtests are separate -
they work with
Speaking from experience (Reaper), I can say that developing a sidecar
admin / repair tool out of tree that's compatible with multiple versions
really isn't that big of a problem. We've been doing it for a while now.
Pushing it back means it’s a bigger risk later on. I’m +.5 on upgrading now
On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID
> Given that we're so close to the 9/1 date, I would err on the side of
> caution especially given the low value prop. If someone does run
I fired up trunk to check something, and noticed this:
INFO [Service Thread] 2018-08-08 15:01:36,723 GCInspector.java:290 - G1
Young Generation GC in 339ms. G1 Eden Space: 4634705920 -> 0; G1 Old Gen:
1190138352 -> 1435504616; G1 Survivor Space: 406847488 -> 301989888;
which I thought was a
+1 to worklog
On Mon, Aug 6, 2018 at 9:44 AM Ariel Weisberg wrote:
> Great idea. +1 to moving it to the work log.
> On Mon, Aug 6, 2018, at 12:40 PM, Aleksey Yeshchenko wrote:
> > Nice indeed. I assume it also doesn’t spam commits@ when done this way,
> > in which
My interpretation of Nate's statement was that since there would be a bunch
of us at Lynn's event, we might as well do NGCC at the same time.
On Thu, Jul 26, 2018 at 9:03 PM Ben Bromhead wrote:
> It sounds like there may be an appetite for something, but the NGCC in its
> current format is
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler
> > I propose the following artifacts for release as 2.2.13.
> > sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> > Git:
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> On Wed, Jul 25, 2018 at 12:16 AM, Michael Shuler
> > I propose the following artifacts for release as 3.11.3.
> > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> > Git:
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler
> > I propose the following artifacts for release as 3.0.17.
> > sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> > Git:
I've come around on this, I think the long and short term benefits
will be worth it.
On Fri, Jul 13, 2018 at 11:17 AM Vinay Chella
> +1 nb
> Vinay Chella
> On Fri, Jul 13, 2018 at 11:15 AM Michael Shuler
> > +0
> > There are pros and cons. I do hope
> Deferring huge amount of commits gives rebase/redo hell. That's the
> biggest impact and the order in which these deferred commits are then
> actually committed can make it more painful or less painful depending on
> the commit. And that in turn will have to then wait for each contributor
ion to need it - besides
> discouraging a new contributor who, let’s be honest, was going to have their
> patch languish for a few months while somebody found time to review it
> anyway. At least this way we can give them a decent excuse!
> > On 10 Jul 2018, at 10:43
he community's prevailing
> rules around commit, and that you’re competent to do so.
> If the community wants to change those rules you’re trusted to follow, how
> does this modify your right, or the trust emplaced in you?
> > On 10 Jul 2018
I guess I look at the initial voting in of committers as the process
by which people are trusted to merge things in. This proposed process
revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
picked) wants to merge a new feature into trunk during the freeze, now
they're not allowed?
3 PM, sankalp kohli
> > wrote:
> > >
> > > How is this preventing someone from working and collaborating on an
> > Apache
> > > Project? You can still collaborate on making 4.0 more stable.
> > >
> > > Why will these committers
e things here. So if you are -1 on this, please help
> us propose something else to get these tests pass?
> And thanks for giving your feedback.
> On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad wrote:
> > Not everyone wants to work and collaborate the way you do. It seems
> features be used?
> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad wrote:
> > I don't see how changing the process and banning feature commits is
> > going to be any help to the project. There may be a couple committers
> > who are interested in commi
> > > >>> This is more of a call to action and announcement of intent than an
> > > >>> attempt to enforce policy; we can and probably will branch off 4.0,
> > > and
> > > >>> keep trunk technically active. But so long as there
I agree with Josh. I don’t see how changing the convention around trunk
will improve the process, seems like it’ll only introduce a handful of
rollback commits when people forget.
Other than that, it all makes sense to me.
I’ve been working on a workload centric stress tool on and off for a
lead of the OS vendors that people will be deploying
> Cassandra on top of. And those will not be dropping Python 2 at the end of
> the year.
> > On Jun 1, 2018, at 12:37 PM, Jonathan Haddad wrote:
> > Both can work. I did a lot of the work on t
> think it will be more than 2 years before people begin asking what
> Python 2 was.
> On 06/01/2018 10:10 AM, Jonathan Haddad wrote:
> > Supporting both as a next step is logical, removing support for 2 in the
> > next year or two seems reasonable enough. Gotta
Supporting both as a next step is logical, removing support for 2 in the
next year or two seems reasonable enough. Gotta rip the band aid off at
On Fri, Jun 1, 2018 at 2:34 AM Michael Burman wrote:
> Deprecating in this context does not mean removing it or it being
Personally I don’t mind dropping support for previsous java versions.
On Fri, May 25, 2018 at 6:33 AM J. D. Jordan
> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> wise, and leaves people’s options open.
> > On May
DataStax invested millions of dollars into Cassandra, tens of thousands of
man hours, hosted hundreds of events and has been a major factor in the
success of the project.
ScyllaDB wants us to change the C* protocol in order to improve features in
a competing database which contributes nothing
>From where I stand it looks like you've got only two options for any
feature that involves updating the protocol:
1. Don't built the feature
2. Built it in Cassanda & scylladb, update the drivers accordingly
I don't think you have a third option, which is built it only in ScyllaDB,
Avi, if this is something that matters to you, you're more than welcome to
submit a patch to both this project and to the different drivers. Getting
the first 2 optimizations into 4.0 would be nice, I'm sure someone would be
happy to work with you on it.
The third, I can't see why we'd need that
There's always more stuff to try to shoehorn in. We've done big releases
with all the things, it never was stable. We tried the opposite end of the
spectrum, release every month, that really wasn't great either. Personally
I'd be OK with stopping new features by the end of this month and aiming
Off the top of my head I can remember clusters with 600 or 700 nodes with
Not the best situation, but it’s real. 256 has been the default for better
On Thu, Apr 5, 2018 at 7:41 PM Joseph Lynch wrote:
> > We see this in larger clusters regularly.
That’s exactly what I was thinking too.
There’s also nothing preventing features from being merged into trunk after
we create the 4.0 branch, which in my opinion is a better approach than
trying to jam everything in right before the release.
On Thu, Apr 5, 2018 at 12:06 PM Jason Brown
To be fair, reaper in 2016 only worked with 2.0 and was just sitting
around, more or less.
Since then we've had 401 commits changing tens of thousands of lines of
code, dealing with fault tolerance, repair retries, scalability, etc.
We've had 1 reaper node managing repairs across dozens of
As requested, I'm alerting the ML that I've got the first patch of several
to come. This one only addresses the ColumnFamilyStore class - and only
changes the name. There's follow up tickets to change method and variable
names. As we agreed, I'm doing this incrementally, so please let's keep
se with a runtime that's
> likely EOL shortly after?
> On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad <j...@jonhaddad.com>
> > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
> > require it for Cassandra 4. At this point I feel like we
Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
require it for Cassandra 4. At this point I feel like we should already be
targeting Java 10 at a minimum.
Personally I'd prefer not to tie our releases to any vendor / product /
package's release schedule.
On Fri, Mar 23,
You could use a load balancing policy at the driver level to do what you
want, mixed with the existing consistency levels as Jeff suggested.
On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller
> But we COULD have CL2 write (for RF4)
> The extension to this idea
There's an incredible amount of work that would need to be done in order to
make any of this happen. Basically a full rewrite of the entire codebase.
Years of effort.
The codebase would have to move to a shared-nothing actor & message based
communication mechanism before any of this is possible.
Hey Micke, very cool you're looking to improve C*'s performance, we would
absolutely benefit from it.
Have you done any other benchmarks beside the micro one to determine the
total effect of these metrics on the system overall? Microbenchmarks are a
great way to tune small sections of code but
On Mon, Feb 12, 2018 at 9:51 PM mck wrote:
> > I propose the following artifacts for release as 3.11.2.
> Thanks Michael for the recut, very much appreciated.
> To unsubscribe, e-mail:
Do you need to support TTLs? That might be a bit of an issue.
On Sat, Jan 13, 2018 at 12:41 PM Arthur Kushka wrote:
> Hi folks,
> Currently, I working on custom CQL operator that should return the max
> timestamp for some partition.
> I don't think that scanning of
After an upgrade I recommend running upgrade sstables no matter what the
version change is. If it's not needed, nothing will happen.
On Fri, Oct 13, 2017 at 4:30 AM Steinmaurer, Thomas <
> And extremely useful/important in the field not being a strict
On Thu, Sep 28, 2017 at 1:46 PM Nate McCall wrote:
> On Sep 29, 2017 7:12 AM, "Michael Shuler" wrote:
> I propose the following artifacts for release as 2.1.19.
> sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c
The wiki isn't really used anymore. You can submit patches to improve the
docs in tree now. Fee free to tag me as a reviewer and I'll get to it this
On Sat, Sep 16, 2017 at 10:26 AM Vusal Ahmadoglu
> Could you please give access me to the apache
Agreed with Jeff & Jason.
On Tue, Jun 13, 2017 at 11:45 AM Jeff Jirsa wrote:
> Looks great to me - especially the venue. Date wise, Tuesday (19th) lets
> people fly in on Monday instead of costing a weekend, so selfishly that
> seems better to me.
> On Mon, Jun 12, 2017
Are there guidelines for how to set something like this up or is it tribal
On Wed, May 31, 2017 at 3:05 PM Gary Dusbabek wrote:
> +1. I'm happy to help with logistics.
> Mid-to-late September is good, but so is October.
> On Wed, May 31, 2017
Looks like the docs haven't been rebuilt in a while. There's a handful of
useful merges recently that I'm aware of that would be great to see on
How do they get rebuilt? Who can trigger it?
There's a handful of issues I can think of with shipping everything
in-tree. I'll try to brain dump them here.
* What's included when shipped in tree?
Does every idea get merged in? Do we need 30 different Seed providers? Who
judges what's valuable enough to add? Who maintains it when it
In accordance with the idea that the codebase should be better tested, it
seems to me like things shouldn't be added that aren't testable. If
there's a million unit tests that are insanely comprehensive but for some
reason can never be run, they serve exactly the same value as no tests.
On Tue, Apr 25, 2017 at 2:21 AM Stefan Podkowinski wrote:
> I don't see any reasons not to make this part of our guidelines. The
> idea of having a list of what should be tested in each kind of test
> makes sense. I also like the examples how to improve tests dealing with
Non binding +1
On Wed, Mar 29, 2017 at 7:22 AM Jeff Jirsa wrote:
> Jeff Jirsa
> > On Mar 29, 2017, at 6:21 AM, Jason Brown wrote:
> > Hey all,
> > Following up my thread from a week or two ago (
I created CASSANDRA-13284 a few days ago with the intent of starting a
discussion around the topic of breaking the CQL parser out into a separate
project. I see a few benefits to doing it and was wondering what the folks
here thought as well.
First off, the Java CQL parser would obviously
1 - 100 of 154 matches
Mail list logo