[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257521#comment-13257521
]
Sylvain Lebresne commented on CASSANDRA-4004:
---------------------------------------------
bq. From the standpoint of a new user, this is sophistry.
How is that sophistry, seriously? I think it's very important that the
clustered part of th PK induces an ordering of records (which SQL don't have,
but we're not talking about SQL here, right). It's important because you don't
model things the same way in Cassandra than traditionally you do in SQL: you
denormalize, you model time series etc... for which the notion that there is an
ordering or records is not an implementation detail, nor something dealt with
at query time (contrarily to SQL), but is an important part of the model. It
would be confusing for brand new user to *not* say that ordering is part of the
data model (and again yes, that's a difference with SQL). I also don't see how
saying that is in any way related to being a veteran and whatnot. I 200% agree
that CQL3 is an abstraction and that it is A Good Thing. I'm saying the
ordering induced by the PK should be part of that abstraction.
But then it's natural that SELECT without ORDER BY should return records in
that clustering order, which will indeed not be the same than the order of with
ORDER BY ASC *unless* Y is the first clustered key. But if is the first
clustered key, then yes, SELECT and SELECT ORDER BY ASC should be the same (and
they are). But then it's not rocket science to say that if the ordering is
'reversed alphabetical order', then 'z' > 'a' and thus a SELECT ORDER BY ASC
returns 'z' before 'a'.
So I absolutely and strongly refute that this proposal is somehow sophistry and
even more so that it's a negation of the abstractive nature of CQL3 or
influenced by the thrift API any more that the solution you're pushing for.
bq. The other relevant context here is that we decided not to support arbitrary
orderings
I'm either misunderstanding what you call 'arbitrary orderings' or I have not
been part of that discussion. Because if you talk of custom types, then CQL3
does support them (you can declare CREATE TABLE foo (k "myCustomType" PRIMARY
KEY)). And I'm -1 on removing that support, unless someone has compelling
reason to do so because I certainly don't see any and that's useful. And yes, I
do see this as a good reason to go with my proposal, since it's not very
consistent if
{noformat}
CREATE TABLE foo (
k1 uuid,
k2 "myEfficientComplexNumberType",
c text,
PRIMARY KEY (k1, k2)
) WITH CLUSTERING ORDER BY (k2 DESC)
{noformat}
is *not* the same than
{noformat}
CREATE TABLE foo (
k1 uuid,
k2 "myReversedEfficientComplexNumberType",
c text,
PRIMARY KEY (k1, k2)
)
{noformat}
> Add support for ReversedType
> ----------------------------
>
> Key: CASSANDRA-4004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4004
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Trivial
> Fix For: 1.1.1
>
> Attachments: 4004.txt
>
>
> It would be nice to add a native syntax for the use of ReversedType. I'm sure
> there is anything in SQL that we inspired ourselves from, so I would propose
> something like:
> {noformat}
> CREATE TABLE timeseries (
> key text,
> time uuid,
> value text,
> PRIMARY KEY (key, time DESC)
> )
> {noformat}
> Alternatively, the DESC could also be put after the column name definition
> but one argument for putting it in the PK instead is that this only apply to
> keys.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
