cassandra-commits mailing list archives

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

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

Tyler Hobbs commented on CASSANDRA-9664:
----------------------------------------

I've pushed several commits to the [same branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-9664-rebase-3]
to address the review comments.  A few responses inline:

bq. I just remembered that interface now have default functions, so if we can use that, that
works for me.

Unfortunately, default functions can't override inherited functions like toString.  However,
I made Term.Literal an abstract class with {{toString()}} defined, which works quite nicely
with minimal pointless code.

bq. I don't think the Term.Literal thing works, because a collection can contain a function
call and yet FunctionCall.Raw is not a Term.Literal

Good catch.  I've made the changes you suggested and added some additional tests around this.

bq. Not sure to understand why the initialization of select and query in View.java is delayed.
Are you worried about MV creation schema changes arriving before other schema changes it depends
on on some nodes?

No, it's about the schema initialization sequence during startup.  I've updated the comment
to explain this better; let me know if you still have questions.

bq.  I think we should just remove the existing selects and replace its current call

I meant to do this and forgot to.  That's taken care of now, thanks.

bq. in Operator.java, can make readFrom call the new fromValue.

This was actually unused (after storing {{where_clause}} as a single string), so I've removed
it.

bq. Yes, pretty please, let's push that to 3.2.

Okay, I've created CASSANDRA-10368 as a follow-up.

bq. I assume the last rebase was just that, a rebase.

Yes, no real changes there.

Pending CI tests:

* [3.0 testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-9664-rebase-3-testall/]
* [3.0 dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-9664-rebase-3-dtest/]

* [trunk testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-9664-trunk-testall/]
* [trunk dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-9664-trunk-dtest/]

> 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