[
https://issues.apache.org/jira/browse/BEAM-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808161#comment-16808161
]
Ismaël Mejía commented on BEAM-6324:
------------------------------------
Well the good direction is something that we could argue from the maintenance
point of view. I don't consider that Beam should maintain a 'home made'
QueryBuilder for Cassandra if could do it with a simple CQL expression. What is
the issue with `ALLOW FILTERING` ?
I agree 100% that the idea of a parser is out of scope too. Notice that for the
moment namespace and table are required just because we need to detect the
ranges for partitioning, but I am interested in all the constraints this can
cause in the query if we validate them. Do you know of other cases [~srfrnk]?
> CassandraIO.Read - Add the ability to provide a filter to the query
> -------------------------------------------------------------------
>
> Key: BEAM-6324
> URL: https://issues.apache.org/jira/browse/BEAM-6324
> Project: Beam
> Issue Type: Improvement
> Components: io-java-cassandra
> Reporter: Shahar Frank
> Assignee: Shahar Frank
> Priority: Major
> Labels: performance, pull-request-available, triaged
> Fix For: Not applicable
>
> Time Spent: 12h 50m
> Remaining Estimate: 0h
>
> CassandraIO.Read doesn't support using WHERE to filter the input at the
> source (In Cassandra) which might provide great performance boost.
> Already implemented by:
> https://github.com/apache/beam/pull/7340
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
