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 18:18:41 GMT


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:
>             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