[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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 in
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: 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, 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
