cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4004) Add support for ReversedType
Date Thu, 19 Apr 2012 15:20:40 GMT


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:

.           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));

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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message