[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257539#comment-13257539
]
Jonathan Ellis commented on CASSANDRA-4004:
-------------------------------------------
bq. I'm either misunderstanding what you call 'arbitrary orderings' or I have
not been part of that discussion
I think you are misunderstanding. This is what I'm referring to:
{code}
. if (stmt.parameters.orderBy != null)
{
CFDefinition.Name name = cfDef.get(stmt.parameters.orderBy);
if (name == null)
throw new InvalidRequestException(String.format("Order by
on unknown column %s", stmt.parameters.orderBy));
if (name.kind != CFDefinition.Name.Kind.COLUMN_ALIAS ||
name.position != 0)
throw new InvalidRequestException(String.format("Order by
is currently only supported on the second column of the PRIMARY KEY (if any),
got %s", stmt.parameters.orderBy));
}
{code}
bq. How is that sophistry, seriously?
"ORDER BY X DESC" does not mean "give me them in the reverse order that Xes are
in on disk", it means "give me larger values before smaller ones." This isn't
open for debate, it's a very clear requirement.
Remember that clustering is not new ground for databases; SQL has been there,
done that. As I mentioned when we were designing the CQL3 schema syntax,
RDBMSes have had a concept of clustered indexes for a long, long time. But
clustering on an index ASC or DESC does not affect the results other than as an
optimization; when you ORDER BY X, that's what you get.
SQL and CQL are declarative languages: "Here is what I want; you figure out how
to give me the results." This has proved a good design. Modifying the
semantics of a query based on index or clustering or other declarations
elsewhere has ZERO precedent and is bad design to boot; you don't want users to
have to consult their DDL when debugging, to know what results a query will
give.
Thus, the only design that makes sense in the larger context of a declarative
language is to treat the clustering as an optimization as I've described (or
"as an index", if you prefer), and continue to reject ORDER BY requests that
are neither forward- nor reverse-clustered.
> 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
