[
https://issues.apache.org/jira/browse/CASSANDRA-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257619#comment-13257619
]
Sylvain Lebresne commented on CASSANDRA-4004:
---------------------------------------------
bq. Nothing, except that it's a separate ticket's worth of work.
Oh ok. For the records I didn't implied otherwise.
bq. But that's not the same as reverse-clustering on a type: "y int ... PRIMARY
KEY (x, y DESC)" (to use your syntax) is NOT the same as "y ReversedInt ...
PRIMARY KEY (x, y)." In the former, ORDER BY Y DESC
What?! I said that I wasn't sure my syntax was good. But with all I've said I
expected it was clear that what I want to do with this ticket from day one is
to allow to define "y ReversedInt ... PRIMARY KEY" but without having to write
a custom java class since we don't have to and that is *exactly* what my patch
implements. I'm fine saying my syntax suck and allow to write is "y
reversed(int) .. PK". But to be clear, I don't think that option is a bad fit
at all for CQL3, and that's not the C* veteran talk.
bq. In the former, ORDER BY Y DESC should give larger Y before smaller (that
is, 100 before 1); in the latter, the reverse
To my defence, you're attributing *your* semantic to *my* made up syntax (which
again, may be is counter-intuitive to you with your background but is really
not to me, and I made it clear that it was a suggestion. I even said in the
description that "Alternatively, the DESC could also be put after the column
name definition").
bq. I really don't see the distinction between saying "disk order" and
"clustering order," as in "the clustered part of th PK induces an ordering of
records ...
Maybe with the reversed(int) syntax it makes it more clear, but when I talk
about ordering of records, I'm saying that we should say that in CQL 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 (though it will but that's an implementation detail). In other words, and
somewhat unrelated to this issue, I think there would be value to say that the
order of SELECT without any ORDER BY is something defined by CQL (while SQL
does not do that). I think there would be value because I think it helps
understanding which model are a good fit for CQL.
Now, and to sum up, I think that having the "y reversed(int)" syntax has the
following advantages over just allowing to change the on-disk order:
# 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. Typically, it means that
'y reversed("myCustomType")' is the same than 'y "myReversedCustomType"' which
has a nice consistency to it. In the alternative, and even though I'm *not*
saying it's ill defined in any way, I do think that have a form of syntactic
double negation that is not equivalent to removing both is kind of weird.
# Though that seems to be very clear to you, 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 (and by that I mean 'does not semantically mean "x
reversed(type)"').
# With that solution, we can maintain (without doing anything) the fact that a
select without ORDERING respect the ordering implied by the "clustering". I
think it's convenient for C*. Again, lots of efficient model for C* uses that
ordering, so it feels like a better idea to say 'oh, and contrarily to SQL the
order of records in a table is defined (and thus the default ordering or
SELECT) and lots of good modeling pattern for C* rely on this'.
> 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
