[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15486896#comment-15486896
]
Maxim Podkolzine commented on CASSANDRA-11456:
--
[~beobal] is it possible to port the fix to 3.5 as well?
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Labels: sasi
> Fix For: 3.6
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15486942#comment-15486942
]
Sam Tunnicliffe commented on CASSANDRA-11456:
-
[~maximp] Sorry, but the tick tock release schedule doesn't work like that.
Only critical security fixes would warrant a 3.5.1 release I'm afraid. That
said, I believe that the patch can be trivially applied to 3.5, so if it's an
absolute blocker for you, you could build your own version (though I would
recommend thoroughly testing that before deploying to production of course).
background on tick-tock:
[summary|https://www.pythian.com/blog/cassandra-version-production/] &
[detail|https://lists.apache.org/thread.html/72bbd3bf1262061176ca455b888238c75e38cd14bad66073059f025d@1433946587@%3Cuser.cassandra.apache.org%3E]
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Labels: sasi
> Fix For: 3.6
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487016#comment-15487016
]
Maxim Podkolzine commented on CASSANDRA-11456:
--
[~beobal] Oh, it's so unfortunate.
We're currently using 3.5, have tried 3.7 and it turned out to be slower. So
we're evaluating 3.6 and probably will stick with that.
But in case it fails, I don't see any workaround to construct a LIKE constraint
in 3.5 with the query builder.
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Labels: sasi
> Fix For: 3.6
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218661#comment-15218661
]
Pavel Yaskevich commented on CASSANDRA-11456:
-
This is actually going to be pretty tough to implement since actual type of
LIKE operator (LIKE_\{PREFIX, SUFFIX, ...\}) is determined by the value and we
can't get a value while building restrictions which means we can't say if
restriction matches index etc. until it's too late already.
I guess we could cheat in LikeRestriction\#isSupportedBy(Index) method and just
accept purely based on the column definition and fail once query is actually
executed since that's only when we will be able to properly determine a type of
LIKE statement.
Or, as an alternative, we could support something like {{SELECT * FROM X WHERE
user_name LIKE '?%'}} so only values of the LIKE could be bind, but I'm not
sure if that's even is currently feasible in CQL.
WDYT, [~beobal]?
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 3.5
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219078#comment-15219078
]
Pavel Yaskevich commented on CASSANDRA-11456:
-
If we wanted to go with LikeRestriction changes it would means that we need to
add base Operator.LIKE which will be converted into appropriate type at
statement execution time.
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 3.6
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219923#comment-15219923
]
Sam Tunnicliffe commented on CASSANDRA-11456:
-
[~xedin] sounds reasonable. I've pushed a branch with a quick implementation,
wdyt?
||branch||testall||dtest||
|[11456-trunk|https://github.com/beobal/cassandra/tree/11456-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-11456-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-11456-trunk-dtest]|
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 3.6
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11456) support for PreparedStatement with LIKE
[
https://issues.apache.org/jira/browse/CASSANDRA-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15220466#comment-15220466
]
Pavel Yaskevich commented on CASSANDRA-11456:
-
[~beobal] LGTM, +1.
> support for PreparedStatement with LIKE
> ---
>
> Key: CASSANDRA-11456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11456
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Pavel Yaskevich
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.6
>
>
> Using the Java driver for example:
> {code}
> PreparedStatement pst = session.prepare("select * from test.users where
> first_name LIKE ?");
> BoundStatement bs = pst.bind("Jon%");
> {code}
> The first line fails with {{SyntaxError: line 1:47 mismatched input '?'
> expecting STRING_LITERAL}} (which makes sense since it's how it's declared in
> the grammar). Other operators declare the right-hand side value as a
> {{Term.Raw}}, which can also be a bind marker.
> I think users will expect to be able to bind the argument this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
