I had complains that my preceding mail was unreadable (thanks gmailfor
fucking my formatting up), so I've posted the same thing with nice
formatting on the JIRA ticket.
--
Sylvain
On Tue, Jan 3, 2012 at 7:08 PM, Sylvain Lebresne wrote:
> Ok, I think I'm warming up to what we're getting at. I wou
Ok, I think I'm warming up to what we're getting at. I would change
thesyntax of the VALUE() thing however. Instead of:CREATE TABLE
timeline ( userid int, posted_at uuid, body string, PRIMARY
KEY(user_id, posted_at), VALUE(body))I would prefer:CREATE COMPACT
TABLE timeline ( userid int,
On Mon, Jan 2, 2012 at 12:55 PM, Jonathan Ellis wrote:
> On Mon, Jan 2, 2012 at 10:53 AM, Eric Evans wrote:
>> In SQL, PRIMARY KEY is a modifier to a column spec, and here PRIMARY
>> KEY(user_id, posted_at, posted_by) reads like a PRIMARY modifier
>> applied to a KEY() function. It's also a litt
On Mon, Jan 2, 2012 at 10:53 AM, Eric Evans wrote:
> In SQL, PRIMARY KEY is a modifier to a column spec, and here PRIMARY
> KEY(user_id, posted_at, posted_by) reads like a PRIMARY modifier
> applied to a KEY() function. It's also a little strange the way it
> appears in the grouping of column spe
Maybe the ship on this has sailed, but I am a bit miffed on "create
table". CQL is going out of its way to make things so easy for people. But
if someone does not understand the concept of a column family making it
easy for them to design something that is an anti-pattern is odd to me.
As an admi
On Sat, Dec 31, 2011 at 1:12 PM, Jonathan Ellis wrote:
> On Fri, Dec 30, 2011 at 12:30 PM, Eric Evans wrote:
>>> CREATE TABLE timeline (
>>> user_id int,
>>> posted_at uuid,
>>> body string,
>>> posted_by string,
>>> PRIMARY KEY(user_id, posted_at, posted_by),
>>> VALUE(body)
>>
On Fri, Dec 30, 2011 at 12:30 PM, Eric Evans wrote:
>> CREATE TABLE timeline (
>> user_id int,
>> posted_at uuid,
>> body string,
>> posted_by string,
>> PRIMARY KEY(user_id, posted_at, posted_by),
>> VALUE(body)
>> );
>
> I think the value declaration also helps in that it's one
On Fri, Dec 30, 2011 at 11:12 AM, Rick Shaw wrote:
> +1 on Gamma
> +1 on haveing capability to specify a value.
>
> My only reservation is the choice of the keword "TABLE", which is going to
> be a source of continued confusion.
TABLE is an alias for COLUMNFAMILY (pretty much always has been); I
On Fri, Dec 30, 2011 at 10:58 AM, Jonathan Ellis wrote:
> I think we're closing in on something workable.
I agree.
> Dropping TRANSPOSED from Gamma as redundant with respect to the
> composite PRIMARY KEY definition.
+1
> Should we support column values in non-sparse rows by adding a
> VALUE(c
+1 on Gamma
+1 on haveing capability to specify a value.
My only reservation is the choice of the keword "TABLE", which is going to
be a source of continued confusion.
On Fri, Dec 30, 2011 at 11:58 AM, Jonathan Ellis wrote:
> I think we're closing in on something workable.
>
> Dropping TRANSPO
I think we're closing in on something workable.
Dropping TRANSPOSED from Gamma as redundant with respect to the
composite PRIMARY KEY definition.
Should we support column values in non-sparse rows by adding a
VALUE(column_name) section?
CREATE TABLE timeline (
user_id int,
posted_at uuid
https://issues.apache.org/jira/browse/CASSANDRA-3685
On Thu, Dec 29, 2011 at 6:34 PM, Eric Evans wrote:
> On Thu, Dec 29, 2011 at 3:44 PM, Jonathan Ellis wrote:
>> That's to allow defining column names that are not text/utf8. So you
>> could have column name "92d21d0a-d6cb-437c-9d3f-b67aa733a19
On Thu, Dec 29, 2011 at 3:44 PM, Jonathan Ellis wrote:
> That's to allow defining column names that are not text/utf8. So you
> could have column name "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" be an
> actual 128-bit uuid binary value internally, not its string
> representation. Put another way, thi
That's to allow defining column names that are not text/utf8. So you
could have column name "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" be an
actual 128-bit uuid binary value internally, not its string
representation. Put another way, this would affect the CqlMetadata
name_types map.
However, we alre
On Wed, Dec 28, 2011 at 1:05 PM, Jonathan Ellis wrote:
> Gamma proposal update:
>
> The more I think about it the less happy I am with omitting support
> for sparse columns. Remember that dense composites may only be
> inserted and deleted, not updated, since they are just a tuple of
> values wit
On Thu, Dec 29, 2011 at 12:04 PM, Jonathan Ellis wrote:
> I've updated the wiki page at
> http://wiki.apache.org/cassandra/Cassandra2474 with a more in-depth
> Background section that hopefully clears up where I'm going with this
> sparse/dense business.
>
> Eric mentioned on IRC that he's uneasy
I've updated the wiki page at
http://wiki.apache.org/cassandra/Cassandra2474 with a more in-depth
Background section that hopefully clears up where I'm going with this
sparse/dense business.
Eric mentioned on IRC that he's uneasy about the PRIMARY KEY syntax
implicitly using the first element of P
Gamma proposal update:
The more I think about it the less happy I am with omitting support
for sparse columns. Remember that dense composites may only be
inserted and deleted, not updated, since they are just a tuple of
values with "column names" determined by schema and/or convention.
I think w
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'
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
Hi,
I +1 Gamma.
Best Regards
--
Pavel Yaskevich
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 visu
22 matches
Mail list logo
