Re: CQL support for compound columns
Hi, I +1 Gamma. Best Regards -- Pavel Yaskevich
Re: CQL support for compound columns
Hmm, I thought I sent this but it was sitting in my Drafts box. Anyway, I've updated http://wiki.apache.org/cassandra/Cassandra2474 to flesh out the earlier proposals and editorialize a little in "Discussion Summary" sections. I'm skeptical that splitting dicussion across Jira and the ML is a big improvement over Jira-only but I'm willing to give it a try. On Tue, Dec 20, 2011 at 4:56 PM, Eric Evans wrote: > There has been a discussion taking place in CASSANDRA-2474[1] > regarding the language and semantics of compound columns in CQL. > Though the issue was only opened in July, and despite extended periods > of inactivity, it is monstrously long. Additionally, the discussion > necessarily includes inline visual aids (tables, graphics, and > verbatim code snippets) that are constantly being revised, which only > compounds (pun intended) the problem. I feel as though this is not > only making the discussion less constructive, but that it may be > scaring people off, (and IMO, this issue could use to be discussed > among a larger group anyway). > > I propose two things, 1) that we move the discussion to this mailing > list, and 2) that we track the various approaches in the wiki. > > For the latter of these, I've stubbed out a page[2] that would > hopefully serve as a starting point. > > Thoughts? > > > [1]: https://issues.apache.org/jira/browse/CASSANDRA-2474 > [2]: http://wiki.apache.org/cassandra/Cassandra2475 > > -- > Eric Evans > Acunu | http://www.acunu.com | @acunu -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: major version release schedule
I think there are couple of different ideas here at play 1) Time to release 2) Quality of the release IMO, the issue that effects most people is the quality of the release. So when someone says that we should slow down the release cycles, I think what they mean is that we should spend more time improving the quality of the releases. Now if there is a process that can ensure the quality of the release, specially the newly added features, I don't think anyone would complain about have quick releases. -- Drew On Dec 20, 2011, at 4:15 PM, Peter Schuller wrote: >> Until recently we were working hard to reach a set of goals that >> culminated in a 1.0 release. I'm not sure we've had a formal >> discussion on it, but just talking to people, there seems to be >> consensus around the idea that we're now shifting our goals and >> priorities around some (usability, stability, etc). If that's the >> case, I think we should at least be open to reevaluating our release >> process and schedule accordingly (whether that means lengthening, >> shorting, and/or simply shifting the barrier-to-entry for stable >> updates). > > Personally I am all for added stability, quality, and testing. But I > don't see how a decreased release frequency will cause more stability. > It may be that decreased release frequency is the necessary *result* > of more stability, but I don't think the causality points in the other > direction unless developers ship things early to get it into the > release. > > But also keep in mind: If we reach a point where major users of > Cassandra need to run on significantly divergent versions of Cassandra > because the release is just too old, the "normal" mainstream release > will end up getting even less testing. > > -- > / Peter Schuller (@scode, http://worldmodscode.wordpress.com)
Row or Supercolumn with approximately n columns
Hello Everybody, Happy Christmas. I know that this topic has come up quiet a few times on Dev and User lists but did not culminate into a solution. http://www.mail-archive.com/user@cassandra.apache.org/msg15367.html The above discussion on User list talks about AbstractCompactionStrategy but I could not find any relevant documentation as its a fairly new feature in Cassandra. Let me state this necessity and use-case again. I need a ColumnFamily (CF) wide or SuperColumn (SC) wide option to approximately limit the number of columns to "n". "n" can vary a lot and the intention is to throw away stale data and not to maintain any hard limit on the CF or SC. Its very useful for storing time-series data where stale data is not necessary. The goal is to achieve this with minimum overhead and since compaction happens all the time it would be clever to implement it as part of compaction. Thanks in advance. Praveen
Re: CQL support for compound columns
On Sat, Dec 24, 2011 at 9:22 AM, Jonathan Ellis wrote: > Hmm, I thought I sent this but it was sitting in my Drafts box. > > Anyway, I've updated http://wiki.apache.org/cassandra/Cassandra2474 to > flesh out the earlier proposals and editorialize a little in > "Discussion Summary" sections. > > I'm skeptical that splitting dicussion across Jira and the ML is a big > improvement over Jira-only but I'm willing to give it a try. Yeah, it probably depends on how much more discussion there will be. The summary in the wiki is fantastic though. It's especially nice being able to see the most recent proposal, up to date with all of the incremental changes, and in one place. Thanks for that! > On Tue, Dec 20, 2011 at 4:56 PM, Eric Evans wrote: >> There has been a discussion taking place in CASSANDRA-2474[1] >> regarding the language and semantics of compound columns in CQL. >> Though the issue was only opened in July, and despite extended periods >> of inactivity, it is monstrously long. Additionally, the discussion >> necessarily includes inline visual aids (tables, graphics, and >> verbatim code snippets) that are constantly being revised, which only >> compounds (pun intended) the problem. I feel as though this is not >> only making the discussion less constructive, but that it may be >> scaring people off, (and IMO, this issue could use to be discussed >> among a larger group anyway). >> >> I propose two things, 1) that we move the discussion to this mailing >> list, and 2) that we track the various approaches in the wiki. -- Eric Evans Acunu | http://www.acunu.com | @acunu
