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).
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.
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.
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" (and ASC always gives you lower 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
is going to be less confusing than
, 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.