[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257663#comment-13257663
]
Jonathan Ellis commented on CASSANDRA-4004:
-------------------------------------------
bq. the model defines an ordering of the rows (where rows is in the sense of
SQL) in tables, order that is defined as the ordering implied by the types of
the "clustered" keys (and to be clear, I don't care what clustering mean in
SQL, I'm reusing the name because you're using it, but I only mean by that term
the fields in the PK after the first one). That doesn't imply the disk order
has to respect it
I think the mental model of rows as predicates, queries returning sets of rows
with no inherent order, and ORDER BY as specifying the desired order, is much
simpler and easier to reason about (see prior point about having to consult DDL
+ QUERY to figure out what order results are supposed to appear in).
bq. To my defence, you're attributing your semantic to my made up syntax
I was trying to say that I view ReversedType(Int32Type) as modification of
Int32Type (which should not affect int ordering) and not a completely new type,
the way the (hypothetical) ReversedInt (or BackwardsInt, or AlmostNotQuiteInt)
type would be. Since the latter isn't really related to an int at all, even
though they look a lot like ints in many respects.
bq. I do think that in most case it's more natural to define a reversed type
rather than just adding an optim for reversed queries.
I don't follow.
bq. I do think that have a form of syntactic double negation that is not
equivalent to removing both is kind of weird... I do think that it's not
necessarily clear per se (i.e to anyone that may not be familiar with SQL
clustering for instance) that "WITH CLUSTERING ORDER (x DESC)" does not change
the ordering
But saying "{{ORDER BY X DESC}} always gives you higher X first" is the only
way to avoid the double negation! Otherwise in your original syntax of PK (X,
Y DESC), the only way to get 1 to sort before 100 is to ask for ORDER BY Y DESC
so the DESC cancel out!
I just can't agree that "ORDER BY Y DESC" giving {1, 100} is going to be less
confusing than {100, 1}, no matter how much we tell users, "No, you see, it's
really just reversing the clustering order, which you already reversed..."
Users may not be familiar with clustering, but they're *very* familiar with
ORDER BY, which as I said above, is very clear on what it does. Clustering is
the closest example of how performance hints should *not* change the semantics
of the query, but indexes fall into the same category.
It may also be worth pointing out that it's worth preserving CQL compatibility
with Hive; queries that execute on both (and to the best of my knowledge CQL3
is a strict subset of Hive SQL) should not give different results.
> 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
