[jira] [Issue Comment Deleted] (CASSANDRA-8272) 2ndary indexes can return stale data
[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Manasseh updated CASSANDRA-8272:
--
Comment: was deleted
(was: Can this be avoided by increasing the consistency level to ALL? I am just
wondering if there is a workaround in order to eliminate the risk.)
> 2ndary indexes can return stale data
>
>
> Key: CASSANDRA-8272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8272
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.1.x
>
>
> When replica return 2ndary index results, it's possible for a single replica
> to return a stale result and that result will be sent back to the user,
> potentially failing the CL contract.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v text);
> CREATE INDEX ON test(v);
> INSERT INTO test(k, v) VALUES (0, 'foo');
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v = 'bar' WHERE k = 0;
> SELECT * FROM test WHERE v = 'foo';
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned (since
> C will return it and A or B will return nothing).
> A potential solution would be that when we read a tombstone in the index (and
> provided we make the index inherit the gcGrace of it's parent CF), instead of
> skipping that tombstone, we'd insert in the result a corresponding range
> tombstone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8272) 2ndary indexes can return stale data
[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232834#comment-15232834
]
Henry Manasseh commented on CASSANDRA-8272:
---
Can this be avoided by increasing the consistency level to ALL? I am just
wondering if there is a workaround in order to eliminate the risk.
> 2ndary indexes can return stale data
>
>
> Key: CASSANDRA-8272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8272
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.1.x
>
>
> When replica return 2ndary index results, it's possible for a single replica
> to return a stale result and that result will be sent back to the user,
> potentially failing the CL contract.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v text);
> CREATE INDEX ON test(v);
> INSERT INTO test(k, v) VALUES (0, 'foo');
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v = 'bar' WHERE k = 0;
> SELECT * FROM test WHERE v = 'foo';
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned (since
> C will return it and A or B will return nothing).
> A potential solution would be that when we read a tombstone in the index (and
> provided we make the index inherit the gcGrace of it's parent CF), instead of
> skipping that tombstone, we'd insert in the result a corresponding range
> tombstone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8488) Filter by UDF
[ https://issues.apache.org/jira/browse/CASSANDRA-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232752#comment-15232752 ] Henry Manasseh commented on CASSANDRA-8488: --- Got it. Yes, that looks like a bigger problem. Thank you for pointing it out. > Filter by UDF > - > > Key: CASSANDRA-8488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8488 > Project: Cassandra > Issue Type: New Feature > Components: CQL, Local Write-Read Paths >Reporter: Jonathan Ellis > Labels: client-impacting, cql, udf > Fix For: 3.x > > > Allow user-defined functions in WHERE clause with ALLOW FILTERING. -- 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=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-8488) Filter by UDF
[ https://issues.apache.org/jira/browse/CASSANDRA-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232719#comment-15232719 ] Henry Manasseh commented on CASSANDRA-8488: --- What do you mean by a UserExpression is for users? Wouldn't filtering based on a UDF be the same thing as filtering by a "user defined filtering expression"? > Filter by UDF > - > > Key: CASSANDRA-8488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8488 > Project: Cassandra > Issue Type: New Feature > Components: CQL, Local Write-Read Paths >Reporter: Jonathan Ellis > Labels: client-impacting, cql, udf > Fix For: 3.x > > > Allow user-defined functions in WHERE clause with ALLOW FILTERING. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10818) Evaluate exposure of DataType instances from JavaUDF class
[
https://issues.apache.org/jira/browse/CASSANDRA-10818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232677#comment-15232677
]
Henry Manasseh commented on CASSANDRA-10818:
Will this fix go into 3.6?
> Evaluate exposure of DataType instances from JavaUDF class
> --
>
> Key: CASSANDRA-10818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10818
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> Currently UDF implementations cannot create new UDT instances.
> There's no way to create a new UT instance without having the
> {{com.datastax.driver.core.DataType}} to be able to call
> {{com.datastax.driver.core.UserType.newValue()}}.
> From a quick look into the related code in {{JavaUDF}}, {{DataType}} and
> {{UserType}} classes it looks fine to expose information about return and
> argument types via {{JavaUDF}}.
> Have to find some solution for script UDFs - but feels doable, too.
--
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-8488) Filter by UDF
[ https://issues.apache.org/jira/browse/CASSANDRA-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231722#comment-15231722 ] Henry Manasseh commented on CASSANDRA-8488: --- It seems the UDF could be wrapped by a subclass of CustomExpression (or the new UserExpression) let's say UDTWrappedExpression which returns a boolean and injects the wrapped expression into the RowFilter. Would that work as a starting point for the design? For the CQL changes: would something like this work for the syntax? select * from my_table where my_filter_udf(col1, col2, 'some constraint defined as an UDF parameter - text or list, etc.') For the constraint, the UDF would need to be extended to support literals (CASSANDRA-10783). Is that in line with what you were thinking? > Filter by UDF > - > > Key: CASSANDRA-8488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8488 > Project: Cassandra > Issue Type: New Feature > Components: CQL, Local Write-Read Paths >Reporter: Jonathan Ellis > Labels: client-impacting, cql, udf > Fix For: 3.x > > > Allow user-defined functions in WHERE clause with ALLOW FILTERING. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8488) Filter by UDF
[ https://issues.apache.org/jira/browse/CASSANDRA-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231722#comment-15231722 ] Henry Manasseh edited comment on CASSANDRA-8488 at 4/8/16 6:40 AM: --- It seems the UDF could be wrapped by a subclass of CustomExpression (or the new UserExpression) let's say UDTWrappedExpression which returns a boolean and injects the wrapped expression into the RowFilter. Would that work as a starting point for the design? For the CQL changes: would something like this work for the syntax? select * from my_table where my_filter_udf(col1, col2, 'some constraint defined as an UDF parameter - text or list, etc.') For the constraint, the UDF would need to be extended to support literals (CASSANDRA-10783). Is that in line with what you were thinking [~jbellis]? was (Author: henryman): It seems the UDF could be wrapped by a subclass of CustomExpression (or the new UserExpression) let's say UDTWrappedExpression which returns a boolean and injects the wrapped expression into the RowFilter. Would that work as a starting point for the design? For the CQL changes: would something like this work for the syntax? select * from my_table where my_filter_udf(col1, col2, 'some constraint defined as an UDF parameter - text or list, etc.') For the constraint, the UDF would need to be extended to support literals (CASSANDRA-10783). Is that in line with what you were thinking? > Filter by UDF > - > > Key: CASSANDRA-8488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8488 > Project: Cassandra > Issue Type: New Feature > Components: CQL, Local Write-Read Paths >Reporter: Jonathan Ellis > Labels: client-impacting, cql, udf > Fix For: 3.x > > > Allow user-defined functions in WHERE clause with ALLOW FILTERING. -- 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] [Updated] (CASSANDRA-11533) Support creating and returning UDTs from a UDF
[
https://issues.apache.org/jira/browse/CASSANDRA-11533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Manasseh updated CASSANDRA-11533:
---
Description:
UDFs support returning UDTs. I see the various test cases which validate by
returning the parameter UDT as the return UDT (which works because it returns
an already existing UDTValue instance). But there is currently no way to create
a new instance of an UDTValue and return it.
It seems creating a new UDTValue instance to return from the UDF would require
getting an instance of the KeyspaceMetadata but that requires access to
packages which are not white listed.
A solution could be to add a method to the JavaUDT class to get the UserType
(encapsulating use of the Schema class).
e.g. change to org.apache.cassandra.cql3.functions.JavaUDF:
protected UserType getUserType(String userTypeName) {
org.apache.cassandra.schema.KeyspaceMetadata ksm =
org.apache.cassandra.config.Schema.instance.getKSMetaData("test_ks");
com.datastax.driver.core.UserType myUdt =
ksm.types.get("my_other_udt").get();
return nyUdt;
}
To illustrate, I wrote a simple UDF to transform one UDT into another UDT. This
fails compilation because Schema is not whitelisted.
CREATE OR REPLACE FUNCTION test_ks.transform_udt (val my_udt)
RETURNS NULL ON NULL INPUT
RETURNS my_other_udt
LANGUAGE java
AS '
String fieldA = val.getString("field_a");
org.apache.cassandra.schema.KeyspaceMetadata ksm =
org.apache.cassandra.config.Schema.instance.getKSMetaData("test_ks");
com.datastax.driver.core.UserType myUdt =
ksm.types.get("my_other_udt").get();
com.datastax.driver.core.UDTValue transformedValue = myUdt.newValue();
transformedValue.setUUID("id", java.util.UUID.randomUUID());
transformedValue.setString("field_a", fieldA);
transformedValue.setString("field_b", "value b");
return transformedValue;
';
This is the error:
:88:InvalidRequest: code=2200 [Invalid query] message="Could not compile
function 'test_ks.transform_udt' from Java source:
org.apache.cassandra.exceptions.InvalidRequestException: Java source
compilation failed:
Line 4: org.apache.cassandra.schema.KeyspaceMetadata cannot be resolved to a
type
Line 4: org.apache.cassandra.config.Schema.instance cannot be resolved to a type
"
was:
UDFs support returning UDTs. I see the various test cases which validate by
returning the parameter UDT as the return UDT (which works because it returns
an already existing UDTValue instance). But there is currently no way to create
a new instance of an UDTValue and return it.
It seems that to accomplish that it would require getting an instance of the
KeyspaceMetadata but that requires use of packages which are not white listed.
A solution could be to add a method to getUserType(String) which calls schema
in the super class org.apache.cassandra.cql3.functions.JavaUDF.
e.g.
protected UserType getUserType(String userTypeName) {
org.apache.cassandra.schema.KeyspaceMetadata ksm =
org.apache.cassandra.config.Schema.instance.getKSMetaData("test_ks");
com.datastax.driver.core.UserType myUdt =
ksm.types.get("my_other_udt").get();
return nyUdt;
}
To illustrate, I wrote a simple UDF to transform one UDT into another UDT. This
fails compilation because Schema is not whitelisted.
CREATE OR REPLACE FUNCTION test_ks.transform_udt (val my_udt)
RETURNS NULL ON NULL INPUT
RETURNS my_other_udt
LANGUAGE java
AS '
String fieldA = val.getString("field_a");
org.apache.cassandra.schema.KeyspaceMetadata ksm =
org.apache.cassandra.config.Schema.instance.getKSMetaData("test_ks");
com.datastax.driver.core.UserType myUdt =
ksm.types.get("my_other_udt").get();
com.datastax.driver.core.UDTValue transformedValue = myUdt.newValue();
transformedValue.setUUID("id", java.util.UUID.randomUUID());
transformedValue.setString("field_a", fieldA);
transformedValue.setString("field_b", "value b");
return transformedValue;
';
This is the error:
:88:InvalidRequest: code=2200 [Invalid query] message="Could not compile
function 'test_ks.transform_udt' from Java source:
org.apache.cassandra.exceptions.InvalidRequestException: Java source
compilation failed:
Line 4: org.apache.cassandra.schema.KeyspaceMetadata cannot be resolved to a
type
Line 4: org.apache.cassandra.config.Schema.instance cannot be resolved to a type
"
> Support creating and returning UDTs from a UDF
> --
>
> Key: CASSANDRA-11533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11533
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
>
> UDFs support returning UDTs. I see the various test cases which validate by
> returning the parameter UDT as the return UDT
[jira] [Created] (CASSANDRA-11533) Support creating and returning UDTs from a UDF
Henry Manasseh created CASSANDRA-11533:
--
Summary: Support creating and returning UDTs from a UDF
Key: CASSANDRA-11533
URL: https://issues.apache.org/jira/browse/CASSANDRA-11533
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Henry Manasseh
Priority: Minor
UDFs support returning UDTs. I see the various test cases which validate by
returning the parameter UDT as the return UDT (which works because it returns
an already existing UDTValue instance). But there is currently no way to create
a new instance of an UDTValue and return it.
It seems that to accomplish that it would require getting an instance of the
KeyspaceMetadata but that requires use of packages which are not white listed.
A solution could be to add a method to getUserType(String) which calls schema
in the super class org.apache.cassandra.cql3.functions.JavaUDF.
e.g.
protected UserType getUserType(String userTypeName) {
org.apache.cassandra.schema.KeyspaceMetadata ksm =
org.apache.cassandra.config.Schema.instance.getKSMetaData("test_ks");
com.datastax.driver.core.UserType myUdt =
ksm.types.get("my_other_udt").get();
return nyUdt;
}
To illustrate, I wrote a simple UDF to transform one UDT into another UDT. This
fails compilation because Schema is not whitelisted.
CREATE OR REPLACE FUNCTION test_ks.transform_udt (val my_udt)
RETURNS NULL ON NULL INPUT
RETURNS my_other_udt
LANGUAGE java
AS '
String fieldA = val.getString("field_a");
org.apache.cassandra.schema.KeyspaceMetadata ksm =
org.apache.cassandra.config.Schema.instance.getKSMetaData("test_ks");
com.datastax.driver.core.UserType myUdt =
ksm.types.get("my_other_udt").get();
com.datastax.driver.core.UDTValue transformedValue = myUdt.newValue();
transformedValue.setUUID("id", java.util.UUID.randomUUID());
transformedValue.setString("field_a", fieldA);
transformedValue.setString("field_b", "value b");
return transformedValue;
';
This is the error:
:88:InvalidRequest: code=2200 [Invalid query] message="Could not compile
function 'test_ks.transform_udt' from Java source:
org.apache.cassandra.exceptions.InvalidRequestException: Java source
compilation failed:
Line 4: org.apache.cassandra.schema.KeyspaceMetadata cannot be resolved to a
type
Line 4: org.apache.cassandra.config.Schema.instance cannot be resolved to a type
"
--
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] [Resolved] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Manasseh resolved CASSANDRA-11458.
Resolution: Won't Fix
CASSANDRA-11295 provides new support for UserExpressions.
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png, addCustomIndexExpression
> change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230988#comment-15230988
]
Henry Manasseh edited comment on CASSANDRA-11458 at 4/7/16 8:57 PM:
I think your new feature CASSANDRA-11295 provides what I need. I already have a
dummy custom index and a hack which removes the custom expression and injects
my own expression subclass which actually works... but I'll plan on
re-implementing based on the new UserExpression class.
was (Author: henryman):
I think your new feature CASSANDRA-11295 provides what I need. I already have a
dummy custom index and a hack which removes the custom expression and injects
my own expression subclass which actually works... but I'll plan on
re-implementing based on the new UserExpression class.
I just need to figure out how to add my user expression subclass to the
RowFilter programmatically via a QueryHandler implementation. [~beobal] Do you
have any pointers to code for a sample UserExpression and QueryHandler
registration code I could use as a starting point? Thank you for any tips.
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png, addCustomIndexExpression
> change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230988#comment-15230988
]
Henry Manasseh commented on CASSANDRA-11458:
I think your new feature CASSANDRA-11295 provides what I need. I already have a
dummy custom index and a hack which removes the custom expression and injects
my own expression subclass which actually works... but I'll plan on
re-implementing based on the new UserExpression class.
I just need to figure out how to add my user expression subclass to the
RowFilter programmatically via a QueryHandler implementation. [~beobal] Do you
have any pointers to code for a sample UserExpression and QueryHandler
registration code I could use as a starting point? Thank you for any tips.
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png, addCustomIndexExpression
> change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230960#comment-15230960
]
Henry Manasseh commented on CASSANDRA-11458:
Sorry for the delayed response. I was out of town.
Yes, what I really need is a custom filter (and not a secondary index) but I
was only able to add it by creating a dummy secondary index. I will check out
the changes from CASSANDRA-11295 later this week. It seems like it may have
what I need. Thank you [~beobal]
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png, addCustomIndexExpression
> change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216819#comment-15216819
]
Henry Manasseh edited comment on CASSANDRA-11458 at 3/29/16 8:57 PM:
-
I can provide a patch for this. I have done the changes locally. Who needs to
approve this change?
I'll write a test if approved.
was (Author: henryman):
I can provide a patch for this. I have done the changes locally. Who needs to
approve this change?
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png, addCustomIndexExpression
> change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Manasseh updated CASSANDRA-11458:
---
Attachment: addCustomIndexExpression change.png
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png, addCustomIndexExpression
> change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216819#comment-15216819
]
Henry Manasseh commented on CASSANDRA-11458:
I can provide a patch for this. I have done the changes locally. Who needs to
approve this change?
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11458) Complete support for CustomExpression
[
https://issues.apache.org/jira/browse/CASSANDRA-11458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Manasseh updated CASSANDRA-11458:
---
Attachment: Custom-expression-Change.png
> Complete support for CustomExpression
> -
>
> Key: CASSANDRA-11458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Henry Manasseh
>Priority: Minor
> Attachments: Custom-expression-Change.png
>
>
> This is a proposal to complete the CustomExpression support first introduced
> as part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
> The current support for custom expressions is partial. There is no clean way
> to implement queries making use of the "exp('index', 'value)" syntax due to
> the fact CustomExpression is declared as final and there is no way to for
> developers to cleanly plug-in their own expressions.
> https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
> The proposal is to make CustomExpression not final so that developers can
> extend and create their own subclass and provide their own isSatisfiedBy
> operation (which currently always returns true).
> Introducing a new custom expression would be done as follows:
> 1. Developer would create a subclass of CustomExpression and override
> isSatisfiedBy method with their logic (public boolean
> isSatisfiedBy(CFMetaData metadata, DecoratedKey partitionKey, Row row))
> 2. This class would be packaged in a jar and copied to the cassandra lib
> directory along with a secondary index class which overrides
> Index.customExpressionValueType
> 2. Create the custom index with an option which identifies the
> CustomExpression subclass (custom_expression_class).
> CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
> 'org.custom.MyCustomIndex'
> WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
> I have prototyped the change and works as designed. In my case I do a type of
> "IN" query filter which will simplify my client logic significantly.
> The default behavior of using the CustomExpression class would be maintained
> if the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11458) Complete support for CustomExpression
Henry Manasseh created CASSANDRA-11458:
--
Summary: Complete support for CustomExpression
Key: CASSANDRA-11458
URL: https://issues.apache.org/jira/browse/CASSANDRA-11458
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Henry Manasseh
Priority: Minor
This is a proposal to complete the CustomExpression support first introduced as
part of https://issues.apache.org/jira/browse/CASSANDRA-10217.
The current support for custom expressions is partial. There is no clean way to
implement queries making use of the "exp('index', 'value)" syntax due to the
fact CustomExpression is declared as final and there is no way to for
developers to cleanly plug-in their own expressions.
https://github.com/apache/cassandra/blob/6e69c75900f3640195130085ad69daa1659184eb/src/java/org/apache/cassandra/db/filter/RowFilter.java#L869
The proposal is to make CustomExpression not final so that developers can
extend and create their own subclass and provide their own isSatisfiedBy
operation (which currently always returns true).
Introducing a new custom expression would be done as follows:
1. Developer would create a subclass of CustomExpression and override
isSatisfiedBy method with their logic (public boolean isSatisfiedBy(CFMetaData
metadata, DecoratedKey partitionKey, Row row))
2. This class would be packaged in a jar and copied to the cassandra lib
directory along with a secondary index class which overrides
Index.customExpressionValueType
2. Create the custom index with an option which identifies the CustomExpression
subclass (custom_expression_class).
CREATE CUSTOM INDEX ON keyspace.my_table(my_indexed_column) USING
'org.custom.MyCustomIndex'
WITH OPTIONS = { 'custom_expression_class': 'org.custom.MyCustomExpression' };
I have prototyped the change and works as designed. In my case I do a type of
"IN" query filter which will simplify my client logic significantly.
The default behavior of using the CustomExpression class would be maintained if
the developer does not provide a custom class in the create index options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-11182) Enable SASI index for collections
[
https://issues.apache.org/jira/browse/CASSANDRA-11182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Manasseh updated CASSANDRA-11182:
---
Comment: was deleted
(was: How would UDTs be handled with this feature?
Will you be supporting indexing UDT fields for collections of UDTs? I just saw
that there is a ticket to allow individual updates to UDT fields
(CASSANDRA-7423) which may facilitate getting the field as a Cell.
)
> Enable SASI index for collections
> -
>
> Key: CASSANDRA-11182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11182
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: DOAN DuyHai
>Priority: Minor
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Right now it is possible with standard Cassandra 2nd index to:
> 1. index list and set elements ( {{WHERE list CONTAINS xxx}})
> 2. index map keys ( {{WHERE map CONTAINS KEYS 'abc' }} )
> 3. index map entries ( {{WHERE map\['key'\]=value}})
> It would be nice to enable these features in SASI too.
> With regard to tokenizing, we might want to allow wildcards ({{%}}) with the
> CONTAINS syntax as well as with index map entries. Ex:
> * {{WHERE list CONTAINS 'John%'}}
> * {{WHERE map CONTAINS KEY '%an%'}}
> * {{WHERE map\['key'\] LIKE '%val%'}}
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11182) Enable SASI index for collections
[
https://issues.apache.org/jira/browse/CASSANDRA-11182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15184037#comment-15184037
]
Henry Manasseh commented on CASSANDRA-11182:
How would UDTs be handled with this feature?
Will you be supporting indexing UDT fields for collections of UDTs? I just saw
that there is a ticket to allow individual updates to UDT fields
(CASSANDRA-7423) which may facilitate getting the field as a Cell.
> Enable SASI index for collections
> -
>
> Key: CASSANDRA-11182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11182
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: DOAN DuyHai
>Priority: Minor
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Right now it is possible with standard Cassandra 2nd index to:
> 1. index list and set elements ( {{WHERE list CONTAINS xxx}})
> 2. index map keys ( {{WHERE map CONTAINS KEYS 'abc' }} )
> 3. index map entries ( {{WHERE map\['key'\]=value}})
> It would be nice to enable these features in SASI too.
> With regard to tokenizing, we might want to allow wildcards ({{%}}) with the
> CONTAINS syntax as well as with index map entries. Ex:
> * {{WHERE list CONTAINS 'John%'}}
> * {{WHERE map CONTAINS KEY '%an%'}}
> * {{WHERE map\['key'\] LIKE '%val%'}}
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11048) JSON queries are not thread safe
[
https://issues.apache.org/jira/browse/CASSANDRA-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126527#comment-15126527
]
Henry Manasseh commented on CASSANDRA-11048:
I agree. Thanks. I am new to the code. The patch from Ivan is pointing me to
the places to look at in the code.
> JSON queries are not thread safe
>
>
> Key: CASSANDRA-11048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11048
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sergio Bossa
>Priority: Critical
> Labels: easyfix, newbie, patch
> Attachments:
> 0001-Fix-thread-unsafe-usage-of-JsonStringEncoder-see-CAS.patch
>
>
> {{org.apache.cassandra.cql3.Json}} uses a shared instance of
> {{JsonStringEncoder}} which is not thread safe (see 1), while
> {{JsonStringEncoder#getInstance()}} should be used (see 2).
> As a consequence, concurrent {{select JSON}} queries often produce wrong
> (sometimes unreadable) results.
> 1.
> http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.jackson/jackson-core-asl/1.9.2/org/codehaus/jackson/io/JsonStringEncoder.java
> 2.
> http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.jackson/jackson-core-asl/1.9.2/org/codehaus/jackson/io/JsonStringEncoder.java#JsonStringEncoder.getInstance%28%29
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11048) JSON queries are not thread safe
[
https://issues.apache.org/jira/browse/CASSANDRA-11048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15117678#comment-15117678
]
Henry Manasseh commented on CASSANDRA-11048:
Is there an existing muti-threaded test suite for Cassandra which could be
extended for this fix? This seems to be more of an integration test in that it
would require a live Cassandra instance with predictable test data. I am not
familiar with the code but I am interested in reviewing it and understanding
how you test multi-threaded code in Cassandra.
I am able to replicate the issue every time (just clicking on a webapp page 4-8
times makes my new application fail).
I wrote this code to replicate and confirmed the patch does fix the issue.
import com.datastax.driver.core.*;
import com.google.gson.JsonObject;
import com.google.gson.JsonParser;
import java.util.Iterator;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
// Load some data with: ./tools/bin/cassandra-stress write n=1000 cl=one -mode
native cql3 -log file=~/temp/create_schema.log
public class JsonBug {
public static void main(String [] arguments) {
String node = "127.0.0.1";
Cluster cluster = Cluster.builder()
.addContactPoint(node)
.build();
Metadata metadata = cluster.getMetadata();
System.out.printf("Connected to cluster: %s\n",
metadata.getClusterName());
for ( Host host : metadata.getAllHosts() ) {
System.out.printf("Datacenter: %s; Host: %s; Rack: %s\n",
host.getDatacenter(), host.getAddress(), host.getRack());
}
final Session session = cluster.connect("keyspace1");
final PreparedStatement prepStatement = session.prepare("select JSON *
from standard1");
ExecutorService executorService = Executors.newFixedThreadPool(250);
for(int i=0; i<100; i++) {
executorService.submit(new Runnable() {
public void run() {
BoundStatement boundStatement = new
BoundStatement(prepStatement);
ResultSet rs = session.execute(boundStatement);
Iterator rsIterator = rs.iterator();
JsonParser parser = new JsonParser();
while(rsIterator.hasNext()) {
Row row = rsIterator.next();
String jsonString = row.getString(0);
//System.out.println(jsonString);
JsonObject jsonObj = (JsonObject)
parser.parse(jsonString);
if(jsonObj.get("key") == null) System.out.println("No
key for " + jsonString + "\n");
if(jsonObj.get("\"C0\"") == null)
System.out.println("No C0 for " + jsonString + "\n");
if(jsonObj.get("\"C1\"") == null)
System.out.println("No C1 for " + jsonString + "\n");
if(jsonObj.get("\"C2\"") == null)
System.out.println("No C2 for " + jsonString + "\n");
if(jsonObj.get("\"C3\"") == null)
System.out.println("No C3 for " + jsonString + "\n");
if(jsonObj.get("\"C4\"") == null)
System.out.println("No C4for " + jsonString + "\n");
}
}
});
}
executorService.shutdown();
try {
executorService.awaitTermination(Long.MAX_VALUE,
TimeUnit.NANOSECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}
cluster.close();
}
}
> JSON queries are not thread safe
>
>
> Key: CASSANDRA-11048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11048
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sergio Bossa
>Priority: Critical
> Labels: easyfix, newbie, patch
> Attachments:
> 0001-Fix-thread-unsafe-usage-of-JsonStringEncoder-see-CAS.patch
>
>
> {{org.apache.cassandra.cql3.Json}} uses a shared instance of
> {{JsonStringEncoder}} which is not thread safe (see 1), while
> {{JsonStringEncoder#getInstance()}} should be used (see 2).
> As a consequence, concurrent {{select JSON}} queries often produce wrong
> (sometimes unreadable) results.
> 1.
> http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.jackson/jackson-core-asl/1.9.2/org/codehaus/jackson/io/JsonStringEncoder.java
> 2.
> http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.jackson/jackson-core-asl/1.9.2/org/codehaus/jackson/io/JsonStringEncoder.java#JsonStringEncoder.getInstance%28%29
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
