[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232724#comment-15232724
]
Henry Manasseh commented on CASSANDRA-11295:
Is this CASSANDRA-8273 an issue for UserExpression filters?
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.6
>
> Attachments: DummyFilteringRestrictions.java
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232669#comment-15232669
]
Henry Manasseh commented on CASSANDRA-11295:
Thank you.
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.6
>
> Attachments: DummyFilteringRestrictions.java
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231705#comment-15231705
]
Henry Manasseh commented on CASSANDRA-11295:
I wonder if this could fullfill the same function as CASSANDRA-8488 entered by
[~jbellis]
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.6
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231089#comment-15231089
]
Henry Manasseh commented on CASSANDRA-11295:
This looks useful for a query I am implementing. I looked at the code for
TestQueryHandler and have some questions.
1. How do you access the RowFilter from within the QueryHandler so that I could
call rowFilter.addUserExpression(UserExpression e) to register my custom
UserExpression?
2. Is a custom payload the only way to pass inputs to the user expression at
the moment (until there is a CQL syntax)?
If you have a sample you used for development/testing... would it be possible
to post to either Jira, github or via email? Thank you for any tips.
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.6
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231071#comment-15231071
]
Henry Manasseh commented on CASSANDRA-11295:
For the a CQL syntax, how about using a syntax similar to a UDF?
SELECT * FROM ks.t1 WHERE my_custom_filter('some arbitrary constraint to be
applied by custom filter');
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.6
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15226240#comment-15226240
]
Sylvain Lebresne commented on CASSANDRA-11295:
--
Lgtm, +1.
Nit: the patch removes the {{final}} from {{class CustomExpression}}. It's
really not a big deal but I guess that's not necessary anymore.
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15177999#comment-15177999
]
Sam Tunnicliffe commented on CASSANDRA-11295:
-
Force-pushed an update which adds a new expression type, {{UserExpression}}, to
preserve {{CustomExpression}} for it's original intended use and avoid
overloading it. {{UserExpression}} is declared abstract and concrete
implementations must be registered before they're used to ensure that they can
be correctly deserialized. In general, I think this is a cleaner and more
robust solution, though use of such expressions during upgrades will still
require some finesse.
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11295) Make custom filtering more extensible via custom classes
[
https://issues.apache.org/jira/browse/CASSANDRA-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15175368#comment-15175368
]
Sam Tunnicliffe commented on CASSANDRA-11295:
-
Pushed a branch with fairly trivial changes to allow the serializer for custom
expressions to be plugged in via a system property. In the usual case,
behaviour remains identical with before, so it's very low impact. The first new
commit exposes a bit more of a statement's restrictions to the {{QueryHandler}}.
||branch||testall||dtest||
|[11295-trunk|https://github.com/beobal/cassandra/tree/11295-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-11295-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-11295-trunk-dtest]|
> Make custom filtering more extensible via custom classes
> -
>
> Key: CASSANDRA-11295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11295
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> At the moment, the implementation of {{RowFilter.CustomExpression}} is
> tightly bound to the syntax designed to support non-CQL search syntax for
> custom 2i implementations. It might be interesting to decouple the two things
> by making the custom expression implementation and serialization a bit more
> pluggable. This would allow users to add their own custom expression
> implementations to experiment with custom filtering strategies without having
> to patch the C* source. As a minimally invasive first step, custom
> expressions could be added programmatically via {{QueryHandler}}. Further
> down the line, if this proves useful and we can figure out some reasonable
> syntax we could think about adding the capability in CQL in a separate
> ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
