cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9664) Allow MV's select statements to be more complex
Date Fri, 18 Sep 2015 08:31:05 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14805213#comment-14805213
] 

Sylvain Lebresne commented on CASSANDRA-9664:
---------------------------------------------

bq. I made Term.Literal an abstract class with toString() defined

But you forgot to make some classes like {{FunctionCall.Raw}}, {{TypeCast}} and {{AbstractMarker.Raw}}
extensions of {{Term.Literal}}. Truth is, I really don't think we need {{Term.Literal}} since
its only purpose is to make sure we have a proper {{toString()}} method and I see no reason
why we wouldn't want that for each and every {{Term.Raw}}. I only mention not wanting to make
{{Term.Raw}} an abstract class because I though we might get a multi-inheritance problem in
a few places, but it appears it's not the case so let's just make {{Term.Raw}} an abstract
class and get rid of {{Term.Literal}}.

Regarding the last commit, about not checking the row filter for 2i, it seems from the code
that only the {{IN}} case is not currently handled by {{RowFilter}}. At which point I would
have a small preference for just quickly adding code to make it work (it's not too hard) and
let 2i also check the row filter. My reasoning is that:
# it'll be cleaner than having the boolean flag to {{selectsKey}} and {{selectsClustering}}
# it's actually an optimization for 2i. Even though we do check those condition elsewhere,
{{selectsKey}} and {{selectsClustering}} are called before the data query (on the index entry),
so filtering at that point is better. We can even easily avoid checking those condition again
later if we really want to.

Anyway, if you feel adding the code for {{IN}} is too involved, I'm fine pushing that to a
followup, but it feels to me like it's almost simpler to do it "right" from the get go.


> Allow MV's select statements to be more complex
> -----------------------------------------------
>
>                 Key: CASSANDRA-9664
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9664
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Carl Yeksigian
>            Assignee: Tyler Hobbs
>              Labels: client-impacting, doc-impacting
>             Fix For: 3.0.0 rc1
>
>
> [Materialized Views|https://issues.apache.org/jira/browse/CASSANDRA-6477] add support
for a syntax which includes a {{SELECT}} statement, but only allows selection of direct columns,
and does not allow any filtering to take place.
> We should add support to the MV {{SELECT}} statement to bring better parity with the
normal CQL {{SELECT}} statement, specifically simple functions in the selected columns, as
well as specifying a {{WHERE}} clause.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message