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
21 matches
Mail list logo
