Re: Internal Documentation Contribution Guidance

nd CEP-15, it became apparent that we lack any guidance on internal documentation and commenting in the “style guide” - which I also propose we rename to “Contribution Guide” or “Contribution and Style Guide" to better describe the broader role it has taken on.I have put together a starting

Re: Internal Documentation Contribution Guidance

- which I also propose we rename to “Contribution Guide” or > “Contribution and Style Guide" to better describe the broader role it has > taken on. > > I have put together a starting proposal to kick us off here: > https://docs.google.com/document/d/1qt7xmvEAXm_w9ARb2lVutapB_3il2W

Internal Documentation Contribution Guidance

During public and private discussions around CEP-15, it became apparent that we lack any guidance on internal documentation and commenting in the “style guide” - which I also propose we rename to “Contribution Guide” or “Contribution and Style Guide" to better describe the broader role i

Re: Updating our Code Contribution/Style Guide

he.org Subject: Re: Updating our Code Contribution/Style Guide On Mon, 30 May 2022 at 22:37, Ekaterina Dimitrova mailto:e.dimitr...@gmail.com>> wrote: I also like it, thank you for putting it together. We can always add more and more, but I think the current one is already quite exten

Re: Updating our Code Contribution/Style Guide

On Mon, 30 May 2022 at 22:37, Ekaterina Dimitrova wrote: > I also like it, thank you for putting it together. We can always add more > and more, but I think the current one is already quite extensive. I like > the dependency management point. > The dependency management paragraph, no objection

Re: Updating our Code Contribution/Style Guide

Miklosovic Date: Tuesday, 31 May 2022 at 14:20 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide 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

Re: Updating our Code Contribution/Style Guide

some linters? This > might be a good thing, if we are willing to be liberal with @SupressWarnings. > I’m not sure how we would transition, though, with so many existing warnings. > > > > > > > > From: Ekaterina Dimitrova > Date: Monday, 30 May 2022 at 21:37 > T

Re: Updating our Code Contribution/Style Guide

be liberal with @SupressWarnings. I’m not sure how we would transition, though, with so many existing warnings. From: Ekaterina Dimitrova Date: Monday, 30 May 2022 at 21:37 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide I also like it, thank you for

Re: Updating our Code Contribution/Style Guide

s? 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

Re: Updating our Code Contribution/Style Guide

: *Re: Updating our Code Contribution/Style Guide > > 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. > > > > &g

Re: Updating our Code Contribution/Style Guide

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

Re: Updating our Code Contribution/Style Guide

ay, 14 May 2022 at 20:56 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide On Sat, May 14, 2022 at 11:00 AM Josh McKenzie mailto:jmcken...@apache.org>> wrote: Incidentally, I've found similar value in @ThreadSafe, const, readonly, etc - communications of auth

Re: Updating our Code Contribution/Style Guide

o to > avoid imbuing documents like this with too much power (and making them too > contentious). > > > > I’ll see about tweaking it along with your other suggestions. > > > > *From: *Derek Chen-Becker > *Date: *Saturday, 14 May 2022 at 20:45 > *To: *dev@cassandra.

Re: Updating our Code Contribution/Style Guide

: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

Re: Updating our Code Contribution/Style Guide

On Sat, May 14, 2022 at 11:00 AM Josh McKenzie wrote: > > Incidentally, I've found similar value in @ThreadSafe, const, readonly, > etc - communications of author's intent; being able to signal to future > maintainers helps them make modifications that are more consistent with and > safer with re

Re: Updating our Code Contribution/Style Guide

On Sat, May 14, 2022 at 8:24 AM bened...@apache.org wrote: > > I'm in favor of codifying the usage of @NotNull and @Nullable > stylistically. +1 > > > > I’m in favour of the use of _*one*_ of @Nullable and @NotNull, preferably > the former since we already use it and it’s more reasonable to have

Re: Updating our Code Contribution/Style Guide

> have a very obvious effect. I prefer to leave some decisions to the author, > since we have expressed a strong preference here for the author to consider. > But perhaps a blanket policy would do more good than harm. I could endorse > it, and am relatively neutral. > >

Re: Updating our Code Contribution/Style Guide

22 at 19:12 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide Should we consider @NotNull/@Nullable or other annotations besides @Override? I'm in favor of codifying the usage of @NotNull and @Nullable stylistically. +1 In the exception handling section sho

Re: Updating our Code Contribution/Style Guide

idered, and I appreciate > all of the work that went into it! > > Cheers, > > Derek > > *From: *"bened...@apache.org" > *Reply-To: *"dev@cassandra.apache.org" > *Date: *Friday, May 13, 2022 at 6:41 AM > *To: *"dev@cassandra.apache.o

Re: Updating our Code Contribution/Style Guide

well written and carefully considered, and I appreciate all of the work that went into it! Cheers, Derek From: "bened...@apache.org" Reply-To: "dev@cassandra.apache.org" Date: Friday, May 13, 2022 at 6:41 AM To: "dev@cassandra.apache.org" Subject: RE: [EXTERNAL]Updat

Re: Updating our Code Contribution/Style Guide

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

Re: Updating our Code Contribution/Style Guide

> It looks like the doc already specified this behaviour for ternary > operator line wrapping. For your proposal I’ve also added the following: > > > > It is usually preferable to carry the operator for multiline expressions, > with the exception of some multiline string literals. > > > > Does that

Re: Updating our Code Contribution/Style Guide

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

Re: Updating our Code Contribution/Style Guide

at 20:56 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide > 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

Re: Updating our Code Contribution/Style Guide

> 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

Re: Updating our Code Contribution/Style Guide

ject: Re: Updating our Code Contribution/Style Guide On Tue, 15 Mar 2022 at 11:46, Ruslan Fomkin mailto:ruslan.fom...@gmail.com>> wrote: … I support Jacek’s request to have each argument on a separate line when they are many and need to be placed on multiple lines. For me it takes less ef

Re: Updating our Code Contribution/Style Guide

Regarding `instance()` method / `instance` field - to clarify my point - we usually use that in many places. While it is quite easy to access by method rather than by a field from the beginning, regardless if there is a need for a mock immediately or not, it would be a much bigger change in terms o

Re: Updating our Code Contribution/Style Guide

On Tue, 15 Mar 2022 at 11:46, Ruslan Fomkin wrote: > … > I support Jacek’s request to have each argument on a separate line when > they are many and need to be placed on multiple lines. For me it takes less > effort to grasp arguments on separate lines than when several arguments are > combined o

Re: Updating our Code Contribution/Style Guide

mports we probably want to mass correct them first. It’s not like other > style requirements in that there should not be unintended consequences. A > single (huge) commit to standardise the orders and introduce a build-time > check would be fine IMO. > > > > I also don’t real

Re: Updating our Code Contribution/Style Guide

owski >> Date: Tuesday, 15 March 2022 at 05:18 >> To: dev@cassandra.apache.org >> Subject: Re: Updating our Code Contribution/Style Guide >> >> I do think that we should at least enforce the import order. What is now is >> a complete mess and causes a lot of c

Re: Updating our Code Contribution/Style Guide

> would be fine IMO. > > > > I also don’t really think it is that important. > > > > From: Jacek Lewandowski > Date: Tuesday, 15 March 2022 at 05:18 > To: dev@cassandra.apache.org > Subject: Re: Updating our Code Contribution/Style Guide > > I do think that

Re: Updating our Code Contribution/Style Guide

would be fine IMO. I also don’t really think it is that important. From: Jacek Lewandowski Date: Tuesday, 15 March 2022 at 05:18 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide I do think that we should at least enforce the import order. What is now is a

Re: Updating our Code Contribution/Style Guide

shi > *Date: *Monday, 14 March 2022 at 23:44 > *To: *dev@cassandra.apache.org > *Subject: *Re: Updating our Code Contribution/Style Guide > I am also in favor of updating the style guide. We should ideally have > custom checkstyle configuration that can ensure adherence to the sty

Re: Updating our Code Contribution/Style Guide

into a linter. Plenty of the rules are stated in > a flexible manner, so as to permit breaches where overall legibility and > aesthetics are improved. > > > From: Dinesh Joshi > Date: Monday, 14 March 2022 at 23:44 > To: dev@cassandra.apache.org > Subject: Re: Updating

Re: Updating our Code Contribution/Style Guide

rules are stated in a flexible manner, so as to permit breaches where overall legibility and aesthetics are improved. From: Dinesh Joshi Date: Monday, 14 March 2022 at 23:44 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide I am also in favor of updating the

Re: Updating our Code Contribution/Style Guide

I am also in favor of updating the style guide. We should ideally have custom checkstyle configuration that can ensure adherence to the style guide. I also don't think this is a contended topic. We want to explicitly codify our current practices so new contributors have an easier time writing co

Re: Updating our Code Contribution/Style Guide

hod("a", "b", "c" ) EndpointState removedState = endpointStateMap.stream(endpoint) .map()… From: Jacek Lewandowski Date: Monday, 14 March 2022 at 16:45 To: dev@cassandra.apache.

Re: Updating our Code Contribution/Style Guide

e. I do not know why they are as they are. > > > > > - define continuation indent - currently it is 0 characters > > > > An opening brace introduces any necessary indentation (from the start of > the line, which is perfect for legibility). I am somewhat inlined to >

Re: Updating our Code Contribution/Style Guide

22 at 14:27 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide Hi, I was looking at the document and have some thoughts: - Sometimes, although it would be just a single implementation, interface can make sense for testing purposes - for mocking in particular -

Re: Updating our Code Contribution/Style Guide

Hi, I was looking at the document and have some thoughts: - Sometimes, although it would be just a single implementation, interface can make sense for testing purposes - for mocking in particular - For exception handling, perhaps we should explicitly mention in the guideline that we should alway

Re: Updating our Code Contribution/Style Guide

> we should add Python code style guides to it > Strongly agree. We're hurting ourselves by treating our python as a 2nd class citizen. > 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 > th

Re: Updating our Code Contribution/Style Guide

“discouraged”, but I am not aware of any context where it is helpful today. From: Marcus Eriksson Date: Monday, 14 March 2022 at 12:00 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide Looks good One thing that might be missing is direction on if we should avoid

Re: Updating our Code Contribution/Style Guide

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

Re: Updating our Code Contribution/Style Guide

Looks good One thing that might be missing is direction 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 sho

Re: Updating our Code Contribution/Style Guide

ndra.apache.org *Subject: *Re: Updating our Code Contribution/Style Guide I found there's no mentioning of Python code style at all. If we are going to update the style guide, can this be addressed too? FYI, a quick "flake8" style check shows many existing issues in the Py

Re: Updating our Code Contribution/Style Guide

*Bowen Song > *Date: *Monday, 14 March 2022 at 10:53 > *To: *dev@cassandra.apache.org > *Subject: *Re: Updating our Code Contribution/Style Guide > I found there's no mentioning of Python code style at all. If we are going to > update the style guide, can this be addressed to

Re: Updating our Code Contribution/Style Guide

? From: Bowen Song Date: Monday, 14 March 2022 at 10:53 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide I found there's no mentioning of Python code style at all. If we are going to update the style guide, can this be addressed too? FYI, a quick "fla

Re: Updating our Code Contribution/Style Guide

I think there's two separate issues, the style guide for Python code, and fixing the existing code style. In my opinion, the style guide should come first, and we can follow that to fix the existing code's style. BTW, I can see the changes you made in CASSANDRA-17413 has already been merged in

Re: Updating our Code Contribution/Style Guide

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 Python

Re: Updating our Code Contribution/Style Guide

I found there's no mentioning of Python code style at all. If we are going to update the style guide, can this be addressed too? FYI, a quick "flake8" style check shows many existing issues in the Python code, including libraries imported but unused, redefinition of unused imports and invalid

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 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

Re: Amazon MCS contribution plan

geId=127406622 > " > > It seems permissions on that page are locked down. Could someone please > help us get access to that page? > > -Almero > > > -Original Message- > From: Mick Semb Wever > Sent: Monday, January 13, 2020 11:51 PM > To: de

Re: Amazon MCS contribution plan

> us get access to that page? > > -Almero > > > -Original Message- > From: Mick Semb Wever > Sent: Monday, January 13, 2020 11:51 PM > To: dev@cassandra.apache.org > Subject: Re: Amazon MCS contribution plan > > >> Infrastructure >> I have noticed that

RE: Amazon MCS contribution plan

=127406622"; It seems permissions on that page are locked down. Could someone please help us get access to that page? -Almero -Original Message- From: Mick Semb Wever Sent: Monday, January 13, 2020 11:51 PM To: dev@cassandra.apache.org Subject: Re: Amazon MCS contribution plan &

Re: Amazon MCS contribution plan

plish this, and we'd be happy to make > this capacity available. Can you help us validate that this is the > appropriate capacity, and guide us into how it should be configured? This would be an immense contribution. Thank you Almero (and everyone at AWS). I think others that have

Re: Amazon MCS contribution plan

0, at 3:32 PM, Gouws, Almero wrote: > > Hi Cassandra devs, > > My name is Almero Gouws, I am the head of engineering for Amazon Managed > Apache Cassandra Service (MCS). My team and I are eager to begin contributing > to Apache Cassandra, and I want to share some of the contri

Amazon MCS contribution plan

Hi Cassandra devs, My name is Almero Gouws, I am the head of engineering for Amazon Managed Apache Cassandra Service (MCS). My team and I are eager to begin contributing to Apache Cassandra, and I want to share some of the contribution ideas we have planned. The goal of this thread is to get

Re: Getting started with contribution

ng for you and then > contact reporter, he can give you some hints :) > > 26.09.2017, 17:11, "Pavel Drankov" : >> Hello, >> >> I am a very new in Cassandra, but I have practiced with it for some time. >> And I m looking for my first contribution.

Re: Getting started with contribution

Look through issues with "lhf" label, choose something for you and then contact reporter, he can give you some hints :) 26.09.2017, 17:11, "Pavel Drankov" : > Hello, > > I am a very new in Cassandra, but I have practiced with it for some time. > And I m looki

Getting started with contribution

Hello, I am a very new in Cassandra, but I have practiced with it for some time. And I m looking for my first contribution. Is there a quick win issue to solve? Could you point me out? Best wishes, Pavel

Re: New contribution - Burst Hour Compaction Strategy

Hi Thanks for engaging in this discussion! Cameron, regarding the benchmark, I need to spend some time exploring the stress tool options, but I aim to create a stress test that goes on for a period of at least 48 hours, and then run it for all strategies (with a 24-hour burst for BHCS). I want th

Re: New contribution - Burst Hour Compaction Strategy

Hi Pedro, I did a quick read through of your strategy, and have a few personal thoughts: First, writing a compaction strategy is a lot of work, and it's great to see new contributors take on ambitious projects. There are even a handful of ideas in here that may be useful to other strategies. The

Re: New contribution - Burst Hour Compaction Strategy

The main issue I see with this is "Read all the SSTables and detect which partition keys are present in more than the compaction minimum threshold value" . This is quite expensive and will be using quite a lot of I/O to calculate. What makes writing a compaction strategy so difficult is calculating

Re: New contribution - Burst Hour Compaction Strategy

Hi I've addressed the issues with Git. I believe this is what Stefan asking for: https://github.com/sedulam/cassandra/tree/12201 I've also added more tests for BHCS, including more for wide rows following Jeff's suggestion. Thanks for the directions so far! If there's something else you would lik

Re: New contribution - Burst Hour Compaction Strategy

Hi all Although a couple of people engaged with me directly to talk about BHCS, I would also like to get the community opinion on this, so I thought I could get the discussion started by saying what the advantages would be and in which type of tables BHCS would do a good job. Please keep in mind t

Re: New contribution - Burst Hour Compaction Strategy

GitHub has some good guides on how to use git and make a pull request for a project. https://guides.github.com/introduction/flow/ https://guides.github.com/activities/forking/ > On Jun 10, 2017, at 3:17 PM, Pedro Gordo wrote: > > Hi all > > I've added to JIRA, a document explaining how BHCS w

Re: New contribution - Burst Hour Compaction Strategy

Hi all I've added to JIRA, a document explaining how BHCS works with code snippets, and the motivation behind it. Because I'm not sure we can send attachments to the mailing list, please get the document from JIRA: https://issues.apache.org/jira/browse/CASSANDRA-12201 I'll check how to address th

Re: New contribution - Burst Hour Compaction Strategy

Hi Stefan Thanks for pointing these out. So far, I've only worked collaboratively with SVN, so I wasn't sure how best to address this part of the development with Git. I'll create a document explaining what I've done, hopefully until the end of this week, so that people at least can discuss the st

Re: New contribution - Burst Hour Compaction Strategy

Hello Pedro Thanks for being interested in contributing to Apache Cassandra. Creating a new compaction strategy is not an easy task and there are several things you can do to make it more obvious for other developers to understand what you're up to. First of all, if using github, changes to the c

New contribution - Burst Hour Compaction Strategy

Hi all As part of my MSc project, I've done a new compaction strategy for Cassandra, called Burst Hour Compaction Strategy. You can find the JIRA ticket here: https://issues.apache.org/jira/browse/CASSANDRA-12201 In a nutshell, the background compaction for this strategy is only triggered during

Re: Contribution to apache Cassandra wiki

If you wish to unsubscribe, send an email to dev-unsubscr...@cassandra.apache.org From: Farrukh Saeed Reply-To: "dev@cassandra.apache.org" Date: Tuesday, August 30, 2016 at 2:32 PM To: "dev@cassandra.apache.org" Subject: Re: Contribution to apache Cassandra wiki

Re: Contribution to apache Cassandra wiki

Can someone help me please to take my name out of the mailing list. I am getting way too many. Thanks Farrukh Saeed On Aug 15, 2016, at 10:20 AM, Dave Brosius wrote: try now! --- On 2016-08-14 07:06, Bartek Kowalczyk wrote: Hi, here http://wiki.apache.org/cassandra/FrontPage I found inf

Re: Contribution to apache Cassandra wiki

try now! --- On 2016-08-14 07:06, Bartek Kowalczyk wrote: Hi, here http://wiki.apache.org/cassandra/FrontPage I found information how to contribute, so if it is possible, it is my username: bartekkowalczyk. I wanted to update class names in http://wiki.apache.org/cassandra/ArchitectureCommi

Contribution to apache Cassandra wiki

Hi, here http://wiki.apache.org/cassandra/FrontPage I found information how to contribute, so if it is possible, it is my username: bartekkowalczyk. I wanted to update class names in http://wiki.apache.org/cassandra/ArchitectureCommitLog (these are now longer valid) Cheers !

Re: Compaction strategy contribution

Any code specific questions can be asked here or in #cassandra-dev on freenode. Discussion regarding usefulness etc is probably best to keep in a JIRA ticket. /Marcus On Mon, Jul 11, 2016 at 7:06 PM, Pedro Gordo wrote: > Hi all > > I'm finishing an MSc in which my final project is to implement

Compaction strategy contribution

Hi all I'm finishing an MSc in which my final project is to implement a new compaction strategy in Cassandra. I've discussed the main points of the strategy with other community members and received valuable feedback. However, I understand this will be a tough challenge for someone who has never w

Re: Contribution

Chris and Pedro, Thank you so much for the tips. I will check these out! Regards I would second the suggestion of going over https://academy.datastax.com/ then can check out http://www.datastax.com/dev/blog/deep-into-cassandra-internals Chris On Mon, Mar 28, 2016 at 8:04 AM, Pedro Gordo wro

Re: Contribution

I would second the suggestion of going over https://academy.datastax.com/ then can check out http://www.datastax.com/dev/blog/deep-into-cassandra-internals Chris On Mon, Mar 28, 2016 at 8:04 AM, Pedro Gordo wrote: > Hi! > > I think that the best place to start is to see the DataStax videos. The

Re: Contribution

Hi! I think that the best place to start is to see the DataStax videos. They are really useful and explain things really well. Check them here . Although thee DS101 doesn't contain any deep architecture info, they tell you how Cassandra first came to be. On DS

Contribution

Hey there, I am Salih, a sophomore CS student. I really like Cassandra project and I'd love to contribute to its development. I have read the steps to get up and running and looking for bugs in tracker. However I need to understand the architecture of the system. Therefore I'd appreciate if y

Re: Contribution to Cassandra Community and Branching Strategy

On Mon, May 18, 2015 at 3:05 PM, Dave Brosius wrote: > You can assign your self to an issue in JIRA (if you can't let us know, > and we can add you as a contributor). > Personally, I prefer this step be done on commit to avoid people being on the contributor list without actually producing code.

Re: Contribution to Cassandra Community and Branching Strategy

Thanks! Not sure if i get fully your question, but you can see the various branches, and tags in use here https://git-wip-us.apache.org/repos/asf?p=cassandra.git Typically, if you are targeting a patch for an older release, the patch should be against that older branch, and hopefully it will

Contribution to Cassandra Community and Branching Strategy

Hi, I want to submit patch for Cassandra JIRA tickets. I have some questions: 1. As per http://wiki.apache.org/cassandra/HowToContribute, we need to clone trunk and provide patch on that. So, I need to understand how this patch is going to be merged in 2.0.x and 2.1.x ? 2. Where can I get the d

Re: Contribution: Native REST Layer for Cassandra

Thanks Brian, we'll have a look on Jira. On Tue, Oct 18, 2011 at 3:21 PM, Brian O'Neill wrote: > Jeremy/Jonathan, > > When you finish celebrating the 1.0 release, I just submitted a native rest > layer for Cassandra. > https://issues.apache.org/jira/browse/CASSANDRA-3380 > > It uses JAX-RS and Ap

Contribution: Native REST Layer for Cassandra

Jeremy/Jonathan, When you finish celebrating the 1.0 release, I just submitted a native rest layer for Cassandra. https://issues.apache.org/jira/browse/CASSANDRA-3380 It uses JAX-RS and Apache CXF supporting the following operations (JSON over HTTP): - Create keyspace - Drop keyspace -