[
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)
