[
https://issues.apache.org/jira/browse/CASSANDRA-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728683#comment-14728683
]
Sylvain Lebresne commented on CASSANDRA-9664:
---------------------------------------------
{quote}
The schema I settled on was this:
{noformat}
where_clause frozen<list<tuple<list<text>, int, list<text>>>>
{noformat}
{quote}
I'm actually a little bit worried about this for 2 reasons:
# it's incomprehensible by a human being and will be a bit of a pain for
external tools (like, say, the {{DESCRIBE}} of cqlsh). We've done extensive and
painful work to make the schema tables more understandable and more easy to
translate to their original statement, and this feels like a step backward.
# it's not future proof. For instance, and while the exact plans are not fully
fleshed out, I strongly suspect we'll start to support at least some form of
{{OR}} in the medium-ish term (I also have some ideas for allowing some custom
form of expressions for the sake of custom index that might or might not pan
out, but probably wouldn't work with this if they do).
bq. I also considered storing a single string of the WHERE clause
That would have my preference, mainly for my 2nd reason above: it makes no
assumption on what a WHERE clause may end up supporting in the future. It also
solves my 1st point, even though in all honestly, it does makes it a little
harder for external tools that _would_ prefer a most "parsed" version of the
WHERE clause (but then again, a WHERE clause parser is not _that_ hard if you
really care). Overall, I'd be much more comfortable with it. It does mean we'd
need to modify the parser to parse WHERE clauses separately, but is it really
_that_ hard?
> 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)
