-1
On Mon, Aug 24, 2009 at 12:29 PM, Evan Weaverewea...@gmail.com wrote:
Resolved, that the data model names should be changed in Cassandra 0.5.
Evan
PS. Committers have the most weight, but everyone's voice is heard.
--
Evan Weaver
Evan,
PS. The implementation of column families hasn't changed from
BigTable, but the use in modeling has. Common Cassandra designs are
more row-oriented than column-oriented.
I'm not sure I understand the distinction you're drawing between
row-oriented modeling and column-oriented modeling.
+1
On Fri, Jun 26, 2009 at 10:49 AM, Jonathan Ellisjbel...@gmail.com wrote:
I propose releasing 0.3.0-rc3 as 0.3.0-final.
We've had some unofficial voting on the rc3 thread but this is the
official one. :)
Voting is open for 72h.
binary build is at
There is some (unfinished) code in the current repo on CQL a SQL-like
Cassandra Query Language that is super simple and (AFAIK) limited to single
node queries.
I suspect there are bigger questions to tackle before we get to query
lanuages in the sense we're talking about--
1. Data model --
+1
On Mon, Jun 22, 2009 at 8:14 AM, Jonathan Ellis jbel...@gmail.com wrote:
It's been two weeks since the last code change on the 0.3 branch and
several days since RC2 release with no new bug reports.
I move that we release RC2 as 0.3.0 official.
svn tag:
I'd like for us to continue with Table as well.
I agree with Alexander's argument for what namespaces mean for most
CS domains.
Moving up a notch to a database is also confusing (Do we also have
tables? Are there tablespaces? Different storage engines for each
tablespace?)
We'll have to think of
Won't things like multi-table support break binary compatibility anyway?
We might be stuck with having to write a tool that migrates from a 0.3
format to a 0.4 format.
On Wed, Jun 3, 2009 at 2:44 PM, Jonathan Ellis jbel...@gmail.com wrote:
The fix for 208 [1] is fairly invasive. should we
Looks like there are apache projects that do both:
Nutch had 0.8, 0.8.1, and now 0.9
Ant and Hadoop seem to follow 0.19.0 style numbering.
I don't care either way :)
On Thu, May 14, 2009 at 11:06 AM, Johan Oskarsson jo...@oskarsson.nu wrote:
I guess this time it's my OCD that thinks having a
On a related note, what's the deal with the Start work link? I used
to see it, but not so much for the newer tickets.
On Thu, May 14, 2009 at 12:31 PM, Jonathan Ellis jbel...@gmail.com wrote:
this marks the ticket as I have a patch available so it shows up
here:
and
book-keeping code.
On Wed, Apr 22, 2009 at 9:36 AM, Jonathan Ellis jbel...@gmail.com wrote:
On Wed, Apr 22, 2009 at 11:32 AM, Sandeep Tata sandeep.t...@gmail.com wrote:
Having multiple CFs in a row could be useful for writes. Consider the
case when you use one CF to store the data and another
Depends on what exactly you have in mind ...
Almost all of the storage engine logic is in the db package. I don't
think it would be too hard to make this pluggable so you could slide
in your own DB, say based on Derby/MySQL/BDB etc... I can see how
specialized implementations of the database part
The refactoring question seems to be a bit of thorn:
My understanding was that new committers come in and start with some feature
implement that and then slowly start looking into what more they could do
going forward. It is NOT come in and refactor the hell out of the system
because you like
The compaction optimization that Prashant mentioned is likely to solve
many of the problems that Jun brings up.
We were thinking of tackling this problem ... I've opened a ticket in
JIRA (https://issues.apache.org/jira/browse/CASSANDRA-16)
Avinash, Prashant -- If you guys are already working on
13 matches
Mail list logo
