cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Updated) (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-4004) Add support for ReversedType
Date Fri, 20 Apr 2012 08:30:40 GMT


Sylvain Lebresne updated CASSANDRA-4004:

    Attachment: 4004_alternative.txt

bq. 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

Much simpler and easier than what? You're pretending that what I'm saying is somehow a complete
revolution where it's not. I'm only suggesting that it would be a good idea for CQL to say
that by default rows are returned in a defined order. Saying the order is defined (by opposition
to not be) hardly breaks the mental mode. And that certainly does not change in any way that
ORDER BY would still specify the desired order.

bq. having to consult DDL + QUERY to figure out what order results are supposed to appear

Again, imho that does not apply to my suggestion at all. People already have to know their
DDL for QUERY.  They need to know which column names are defined and which type they have
(since without knowing the type *you cannot know the ordering*). Since *all* I'm suggesting
is a convenient syntax to define "x ReversedInt", and since you can *already* define "x ReversedInt"
(provided you write such AbstractType), my suggestion doesn't change one bit how much people
will have to consult the DDL.

bq. Users may not be familiar with clustering, but they're very familiar with ORDER BY

I've *never* suggested to change the semantic of ORDER BY *at all*. ORDER BY x ASC is defined
as 'return rows in the order induces by the type of x'. I'm suggesting a syntax to define
new types from existing ones. How is that even close to be related to changing what ORDER
BY does?

Anyway, I'm still convinced that adding a simple syntax to allow to define a type with reversed
order given an existing type (custom or predefined) is in fact cleaner from the point of semantic
than the alternative you are suggesting (and it is certainly not the semantic disrupting monster
you're seem to be suggesting it is for a reason that is beyond me), and at a personal level
I find it more natural (as in: the syntax naturally imply the semantic).

But anyway, since we're going nowhere, I'm giving up.

I'm attaching the patch with the alternative you've suggested. I do not think that's the best
solution for CQL but from a pure technical point of point it does is a solution so so be it.

> 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, 4004_alternative.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