[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257568#comment-13257568
]
Sylvain Lebresne commented on CASSANDRA-4004:
---------------------------------------------
bq. This is what I'm referring to:
Wait, 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. How can I reconcile that with "The other relevant
context here is that we decided not to support arbitrary orderings"?
bq. "ORDER BY X DESC" does not mean "give me them in the reverse order that Xes
are in on disk"
I *never* suggested that, not even a little. Not more than you did.
bq. it means "give me larger values before smaller ones." This isn't open for
debate, it's a very clear requirement
Sure. But the definition of larger versus smaller depends on what ordering you
are talking about. This isn't open for debate either. Math have closed that
debate for ages. And SQL is not excluded from that rule, but it just happens
that SQL has default orderings (based on the column type) and you can't define
new ones. But we can do that in CQL. We can independently of this ticket
because of custom types.
Again, once you consider custom types (which we have), you can't hide behind
that the fact that value X is larger than Y depends on the ordering induces by
your custom types. That's the ASC order, and DESC is the reverse of that. If
someone define it's own custom types being "reverseIntegerType", how can you
avoid SELECT ORDER BY DESC to not return 1 before 3? You can't, and returning 1
before 3 absolutely make sense because 1 is larger than 3 if the order is
'reverseInteger'.
bq. 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.
Sure, *nothing* in what I'm suggesting is at odd with that.
bq. Modifying the semantics of a query based on index or clustering
Again, I'm not suggesting any such thing at all. The semantic of a SELECT X
ORDER BY Y depends on what ordering relation is defined for Y *because the
ordering relation is what defines the order*. SQL has a limited and non
customizable set of types *and* (implicitly) define an ordering relation for
each one. If one type was 'thing' it would have to define the ordering of
'thing' otherwise ORDER BY queries wouldn't be properly defined. CQL also has a
default set of types which have associated ordering relation. I'm *only*
suggesting we add a simple syntax so that given a type/relation (a default one
or a custom one btw), we can define the type/ordering relation that validate
the same value but have the reversed ordering.
> 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
