[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257580#comment-13257580
]
Jonathan Ellis edited comment on CASSANDRA-4004 at 4/19/12 4:25 PM:
--------------------------------------------------------------------
bq. what happened to "Third (and this is the big one) I strongly suspect that
we're going to start supporting at least limited run-time ordering in the near
future" from CASSANDRA-3925
Nothing, except that it's a separate ticket's worth of work.
bq. I never suggested that [ORDER BY depends on disk order], not even a little.
Not more than you did.
I really don't see the distinction between saying "disk order" and "clustering
order," as in "the clustered part of th PK induces an ordering of records ...
SELECT without ORDER BY should return records in that clustering order ...
SELECT ORDER BY ASC returns 'z' before 'a'."
But disk order or clustering order, I don't care which you call it; I reject
both as modifiers of the semantics of ASC and DESC. (But again, SELECT with no
explicit ORDER BY is free to return in any order we like.)
bq. the fact that value X is larger than Y depends on the ordering induces by
your custom types
Agreed. But that's not the same as reverse-clustering on a type: "y int ...
PRIMARY KEY (x, y DESC)" (to use your syntax) is NOT the same as "y ReversedInt
... PRIMARY KEY (x, y)." In the former, ORDER BY Y DESC should give larger Y
before smaller (that is, 100 before 1); in the latter, the reverse.
was (Author: jbellis):
bq. what happened to "Third (and this is the big one) I strongly suspect
that we're going to start supporting at least limited run-time ordering in the
near future" from CASSANDRA-3925
Nothing, except that it's a separate ticket's worth of work.
bq. I never suggested that [ORDER BY depends on disk order], not even a little.
Not more than you did.
I really don't see the distinction between saying "disk order" and "clustering
order," as in "the clustered part of th PK induces an ordering of records ...
SELECT without ORDER BY should return records in that clustering order ...
SELECT ORDER BY ASC returns 'z' before 'a'."
But disk order or clustering order, I don't care which you call it; I reject
both as modifiers of the semantics of DESC.
bq. the fact that value X is larger than Y depends on the ordering induces by
your custom types
Agreed. But that's not the same as reverse-clustering on a type: "y int ...
PRIMARY KEY (x, y DESC)" (to use your syntax) is NOT the same as "y ReversedInt
... PRIMARY KEY (x, y)." In the former, ORDER BY Y DESC should give larger Y
before smaller; in the latter, the reverse.
> 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
