[jira] [Commented] (CASSANDRA-13564) Mismatch Documentation on MATERIALIZE VIEW
[ https://issues.apache.org/jira/browse/CASSANDRA-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079737#comment-16079737 ] Kurt Greaves commented on CASSANDRA-13564: -- That error message implies you re-used the entire primary key from the base as the partition key for your MV (potentially also with an extra column not in the base PK). What is the use case here? Can you post the relevant schema? > Mismatch Documentation on MATERIALIZE VIEW > -- > > Key: CASSANDRA-13564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13564 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website, Materialized Views > Environment: 3.10 >Reporter: Nick Hryhoriev > Labels: doc-impacting > > During create MATERIALIZED VIEW with out cluster key. > I've got exception "No columns are defined for Materialized View other than > primary key" > Does it expected behave? Because i can't find nothing about this in > Documentation. But this check exist in code. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13066) Fast streaming with materialized views
[ https://issues.apache.org/jira/browse/CASSANDRA-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079742#comment-16079742 ] Kurt Greaves commented on CASSANDRA-13066: -- +1 what Paulo said. Append only MV's really don't make sense at the moment because of the forced read before write, so really there is little benefit in this improvement unless we group it with functionality to enforce append-only MV's. Also, I think it's generally a bad idea to provide options that will break consistency in known circumstances. Seems to me this option would kind of end up like consistent.rangemovement which is a constant source of problems for users that don't fully understand the implications. You can guarantee people will enable this for MV's that are not append-only. Would there be any objection to move this to be a sub-task of CASSANDRA-9779? > Fast streaming with materialized views > -- > > Key: CASSANDRA-13066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13066 > Project: Cassandra > Issue Type: Improvement > Components: Materialized Views, Streaming and Messaging >Reporter: Benjamin Roth >Assignee: Benjamin Roth > Fix For: 4.0 > > > I propose adding a configuration option to send streams of tables with MVs > not through the regular write path. > This may be either a global option or better a CF option. > Background: > A repair of a CF with an MV that is much out of sync creates many streams. > These streams all go through the regular write path to assert local > consistency of the MV. This again causes a read before write for every single > mutation which again puts a lot of pressure on the node - much more than > simply streaming the SSTable down. > In some cases this can be avoided. Instead of only repairing the base table, > all base + mv tables would have to be repaired. But this can break eventual > consistency between base table and MV. The proposed behaviour is always safe, > when having append-only MVs. It also works when using CL_QUORUM writes but it > cannot be absolutely guaranteed, that a quorum write is applied atomically, > so this can also lead to inconsistencies, if a quorum write is started but > one node dies in the middle of a request. > So, this proposal can help a lot in some situations but also can break > consistency in others. That's why it should be left upon the operator if that > behaviour is appropriate for individual use cases. > This issue came up here: > https://issues.apache.org/jira/browse/CASSANDRA-12888?focusedCommentId=15736599=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15736599 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079644#comment-16079644
]
ZhaoYang commented on CASSANDRA-13573:
--
Some issues are related to {{ColumnMetadata.cellValueType()}} which currently :
{{a}}. if CollectionType, returns value's type; {{b}} otherwise, its own type.
It doesn't handle properly: {{1}}. frozen collection type, {{2}}. non-frozen
udt which requires cellPath to retrieve value's type..
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13067) Integer overflows with file system size reported by Amazon Elastic File System (EFS)
[
https://issues.apache.org/jira/browse/CASSANDRA-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anonymous updated CASSANDRA-13067:
--
Status: In Progress (was: Ready to Commit)
> Integer overflows with file system size reported by Amazon Elastic File
> System (EFS)
>
>
> Key: CASSANDRA-13067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13067
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra in OpenShift running on Amazon EC2 instance
> with EFS mounted for data
>Reporter: Michael Hanselmann
>Assignee: Benjamin Lerer
> Attachments: 0001-Handle-exabyte-sized-filesystems.patch
>
>
> When not explicitly configured Cassandra uses
> [{{nio.FileStore.getTotalSpace}}|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html]
> to determine the total amount of available space in order to [calculate the
> preferred commit log
> size|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L553].
> [Amazon EFS|https://aws.amazon.com/efs/] instances report a filesystem size
> of 8 EiB when empty. [{{getTotalSpace}} causes an integer overflow
> (JDK-8162520)|https://bugs.openjdk.java.net/browse/JDK-8162520] and returns a
> negative number, resulting in a negative preferred size and causing the
> checked integer to throw.
> Overriding {{commitlog_total_space_in_mb}} is not sufficient as
> [{{DataDirectory.getAvailableSpace}}|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/db/Directories.java#L550]
> makes use of {{nio.FileStore.getUsableSpace}}.
> [AMQ-6441] is a comparable issue in ActiveMQ.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13067) Integer overflows with file system size reported by Amazon Elastic File System (EFS)
[
https://issues.apache.org/jira/browse/CASSANDRA-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anonymous updated CASSANDRA-13067:
--
Status: Ready to Commit (was: Patch Available)
> Integer overflows with file system size reported by Amazon Elastic File
> System (EFS)
>
>
> Key: CASSANDRA-13067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13067
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra in OpenShift running on Amazon EC2 instance
> with EFS mounted for data
>Reporter: Michael Hanselmann
>Assignee: Benjamin Lerer
> Attachments: 0001-Handle-exabyte-sized-filesystems.patch
>
>
> When not explicitly configured Cassandra uses
> [{{nio.FileStore.getTotalSpace}}|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html]
> to determine the total amount of available space in order to [calculate the
> preferred commit log
> size|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L553].
> [Amazon EFS|https://aws.amazon.com/efs/] instances report a filesystem size
> of 8 EiB when empty. [{{getTotalSpace}} causes an integer overflow
> (JDK-8162520)|https://bugs.openjdk.java.net/browse/JDK-8162520] and returns a
> negative number, resulting in a negative preferred size and causing the
> checked integer to throw.
> Overriding {{commitlog_total_space_in_mb}} is not sufficient as
> [{{DataDirectory.getAvailableSpace}}|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/db/Directories.java#L550]
> makes use of {{nio.FileStore.getUsableSpace}}.
> [AMQ-6441] is a comparable issue in ActiveMQ.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079565#comment-16079565
]
ZhaoYang commented on CASSANDRA-13573:
--
I think we could use {{`writeRawValue(String)`}} to avoid double escape. Now
that [13592|https://issues.apache.org/jira/browse/CASSANDRA-13592] is merged,
we should have correct json representations for all types.. better than using
{{type.toString}} which, imo, serves a different purposes.
bq. all UDTs were not supported initially because the information to
deserialize the UDT requires the system schema tables to be read (which is
dangerous and we dont want to do)
If there is dependency to local schema tables, I agree not to support UDT and
print raw-bytes instead.
But AFAIK after 8099, there should not be a dependency on schema tables while
deserializing UDT.
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13576) test failure in bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
[
https://issues.apache.org/jira/browse/CASSANDRA-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078214#comment-16078214
]
ZhaoYang edited comment on CASSANDRA-13576 at 7/10/17 3:20 AM:
---
:D LGTM
was (Author: jasonstack):
:D
> test failure in
> bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
> -
>
> Key: CASSANDRA-13576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13576
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Hamm
>Assignee: Alex Petrov
> Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log,
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log,
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/445/testReport/bootstrap_test/TestBootstrap/consistent_range_movement_false_with_rf1_should_succeed_test
> {noformat}
> Error Message
> 31 May 2017 04:28:09 [node3] Missing: ['Starting listening for CQL clients']:
> INFO [main] 2017-05-31 04:18:01,615 YamlConfigura.
> See system.log for remainder
> {noformat}
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 236, in
> consistent_range_movement_false_with_rf1_should_succeed_test
> self._bootstrap_test_with_replica_down(False, rf=1)
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 278, in
> _bootstrap_test_with_replica_down
>
> jvm_args=["-Dcassandra.consistent.rangemovement={}".format(consistent_range_movement)])
> File
> "/home/automaton/venv/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 696, in start
> self.wait_for_binary_interface(from_mark=self.mark)
> File
> "/home/automaton/venv/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 514, in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> File
> "/home/automaton/venv/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 471, in watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + "
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" +
> reads[:50] + ".\nSee {} for remainder".format(filename))
> "31 May 2017 04:28:09 [node3] Missing: ['Starting listening for CQL
> clients']:\nINFO [main] 2017-05-31 04:18:01,615 YamlConfigura.\n
> {noformat}
> {noformat}
> >> begin captured logging <<
> \ndtest: DEBUG: cluster ccm directory:
> /tmp/dtest-PKphwD\ndtest: DEBUG: Done setting configuration options:\n{
> 'initial_token': None,\n'memtable_allocation_type': 'offheap_objects',\n
> 'num_tokens': '32',\n'phi_convict_threshold': 5,\n
> 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
> 1,\n'request_timeout_in_ms': 1,\n
> 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
> 1}\ncassandra.policies: INFO: Using datacenter 'datacenter1' for
> DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify
> a local_dc to the constructor, or limit contact points to local cluster
> nodes\ncassandra.cluster: INFO: New Cassandra host datacenter1> discovered\ncassandra.protocol: WARNING: Server warning: When
> increasing replication factor you need to run a full (-full) repair to
> distribute the data.\ncassandra.connection: WARNING: Heartbeat failed for
> connection (139927174110160) to 127.0.0.2\ncassandra.cluster: WARNING: Host
> 127.0.0.2 has been marked down\ncassandra.pool: WARNING: Error attempting to
> reconnect to 127.0.0.2, scheduling retry in 2.0 seconds: [Errno 111] Tried
> connecting to [('127.0.0.2', 9042)]. Last error: Connection
> refused\ncassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.2,
> scheduling retry in 4.0 seconds: [Errno 111] Tried connecting to
> [('127.0.0.2', 9042)]. Last error: Connection refused\ncassandra.pool:
> WARNING: Error attempting to reconnect to 127.0.0.2, scheduling retry in 8.0
> seconds: [Errno 111] Tried connecting to [('127.0.0.2', 9042)]. Last error:
> Connection refused\ncassandra.pool: WARNING: Error attempting to reconnect to
> 127.0.0.2, scheduling retry in 16.0 seconds: [Errno 111] Tried connecting to
> [('127.0.0.2', 9042)]. Last error: Connection refused\ncassandra.pool:
> WARNING: Error attempting to reconnect to 127.0.0.2, scheduling retry in 32.0
> seconds: [Errno 111] Tried connecting to [('127.0.0.2', 9042)]. Last error:
> Connection refused\ncassandra.pool: WARNING: Error attempting to reconnect to
> 127.0.0.2,
[jira] [Comment Edited] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079806#comment-16079806
]
ZhaoYang edited comment on CASSANDRA-13573 at 7/10/17 3:11 AM:
---
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13573] |
[unit|https://circleci.com/gh/jasonstack/cassandra/124] | dtest |
changes:
1. use {{type.toJSONString()}} with {{json.writeRawValue()}} instead of
{{type.getString()}} to generate readable content
2. {{column.cellValueType}} now : {{a}}. if non-frozen collect, return value
type, {{b}}. otherwise, return current column type.
going to add more dtests on sstabledump, MV and SASI.
was (Author: jasonstack):
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13573] |
[unit|https://circleci.com/gh/jasonstack/cassandra/124] | dtest |
changes:
1. use {{type.toJSONString()}} with {{json.writeRawValue()}} instead of
{{type.getString()}} to generate readable content
2. {{column.cellValueType}} now : a. only if non-frozen collect
going to add more dtests on Dump, MV and SASI.
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13127) Materialized Views: View row expires too soon
[
https://issues.apache.org/jira/browse/CASSANDRA-13127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079873#comment-16079873
]
ZhaoYang commented on CASSANDRA-13127:
--
[~tjake] yes, it will have to read existing data more often.
the extra cases are: when updating base's columns which are not used in view.
If a user has multiple views on a base, read-before-write is very likely to
happen, the original optimization won't help too much.
another naive way is totally disable TTL on table with MV. because it may not
make sense to denormalize a short-life data..
> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" |
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 7
> (1 rows)
> c | p
> ---+---
> 0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 3
> (1 rows)
> c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry
> the TTLs are compared instead of the expiration times, but I'm not sure I'm
> getting that far ahead in the code when updating a column that's not in the
> view.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13680) readBytes needs to clone its data
Hao Zhong created CASSANDRA-13680:
-
Summary: readBytes needs to clone its data
Key: CASSANDRA-13680
URL: https://issues.apache.org/jira/browse/CASSANDRA-13680
Project: Cassandra
Issue Type: Bug
Reporter: Hao Zhong
The code of the ByteBufferUtil_readBytes method is as follow:
{code}
public static ByteBuffer readBytes(ByteBuffer bb, int length)
{
ByteBuffer copy = bb.duplicate();
copy.limit(copy.position() + length);
bb.position(bb.position() + length);
return copy;
}
{code}
I found that CASSANDRA-3179 fixed a related bug. The buggy code is as follow:
{code}
public synchronized ByteBuffer readBytes(int length) throws IOException
{
int remaining = buffer.remaining() - position;
if (length > remaining)
throw new IOException(String.format("mmap segment underflow;
remaining is %d but %d requested",
remaining, length));
ByteBuffer bytes = buffer.duplicate();
bytes.position(buffer.position() + position).limit(buffer.position() +
position + length);
position += length;
return bytes;
}
{code}
The fixed code is:
{code}
public synchronized ByteBuffer readBytes(int length) throws IOException
{
int remaining = buffer.remaining() - position;
if (length > remaining)
throw new IOException(String.format("mmap segment underflow;
remaining is %d but %d requested",
remaining, length));
if (length == 0)
return ByteBufferUtil.EMPTY_BYTE_BUFFER;
ByteBuffer bytes = buffer.duplicate();
bytes.position(buffer.position() + position).limit(buffer.position() +
position + length);
position += length;
// we have to copy the data in case we unreference the underlying
sstable. See CASSANDRA-3179
ByteBuffer clone = ByteBuffer.allocate(bytes.remaining());
clone.put(bytes);
clone.flip();
return clone;
}
{code}
The ByteBufferUtil_readBytes method may be modified in the same way to handle
the similar problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View row expires too soon
[
https://issues.apache.org/jira/browse/CASSANDRA-13127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079873#comment-16079873
]
ZhaoYang edited comment on CASSANDRA-13127 at 7/10/17 5:07 AM:
---
[~tjake] yes, it will have to read existing data more often.
the extra cases are: when updating base's columns which are not used in view.
If a user has multiple views on a base, read-before-write is very likely to
happen, the original optimization won't help too much.
another naive way is to ignore the TTL effect on view in the given example or
totally disable TTL on table with MV. because it may not make sense to
denormalize a short-life data..
was (Author: jasonstack):
[~tjake] yes, it will have to read existing data more often.
the extra cases are: when updating base's columns which are not used in view.
If a user has multiple views on a base, read-before-write is very likely to
happen, the original optimization won't help too much.
another naive way is totally disable TTL on table with MV. because it may not
make sense to denormalize a short-life data..
> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" |
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 7
> (1 rows)
> c | p
> ---+---
> 0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
> p | c | ttl(v)
> ---+---+
> 0 | 0 | 3
> (1 rows)
> c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry
> the TTLs are compared instead of the expiration times, but I'm not sure I'm
> getting that far ahead in the code when updating a column that's not in the
> view.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13681) checkAccess throws exceptions when statement does not exist
Hao Zhong created CASSANDRA-13681:
-
Summary: checkAccess throws exceptions when statement does not
exist
Key: CASSANDRA-13681
URL: https://issues.apache.org/jira/browse/CASSANDRA-13681
Project: Cassandra
Issue Type: Bug
Reporter: Hao Zhong
CASSANDRA-6687 fixed a wrong exception. In DropTableStatement, the buggy code
is:
{code}
public void checkAccess(ClientState state) throws UnauthorizedException,
InvalidRequestException
{
state.hasColumnFamilyAccess(keyspace(), columnFamily(),
Permission.DROP);
}
{code}
The fixed code is:
{code}
public void checkAccess(ClientState state) throws UnauthorizedException,
InvalidRequestException
{
try
{
state.hasColumnFamilyAccess(keyspace(), columnFamily(),
Permission.DROP);
}
catch (InvalidRequestException e)
{
if (!ifExists)
throw e;
}
}
{code}
I found that ModificationStatement_checkAccess can have the same problem, since
it calls state.hasColumnFamilyAccess. In particular, its code is as follow:
{code}
public void checkAccess(ClientState state) throws InvalidRequestException,
UnauthorizedException
{
state.hasColumnFamilyAccess(metadata, Permission.MODIFY);
// CAS updates can be used to simulate a SELECT query, so should
require Permission.SELECT as well.
if (hasConditions())
state.hasColumnFamilyAccess(metadata, Permission.SELECT);
// MV updates need to get the current state from the table, and might
update the views
// Require Permission.SELECT on the base table, and Permission.MODIFY
on the views
Iterator views = View.findAll(keyspace(),
columnFamily()).iterator();
if (views.hasNext())
{
state.hasColumnFamilyAccess(metadata, Permission.SELECT);
do
{
state.hasColumnFamilyAccess(views.next().metadata,
Permission.MODIFY);
} while (views.hasNext());
}
for (Function function : getFunctions())
state.ensureHasPermission(Permission.EXECUTE, function);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079644#comment-16079644
]
ZhaoYang edited comment on CASSANDRA-13573 at 7/10/17 3:07 AM:
---
Some issues are related to {{ColumnMetadata.cellValueType()}} which currently :
{{a}}. if CollectionType, returns value's type; {{b}} otherwise, its own type.
It doesn't handle properly: {{1}}. frozen collection type, {{2}}. non-frozen
udt which requires cellPath to retrieve value's type..
There are 3 kind of usage for {{ColumnMetadata.cellValueType()}}:
1. to check if column is counter type, it's safe
2. used in MV to check if cell value (base's non key column in view's primary
key) is changed.
in the existing implementation, it will get {{cellValueType}} of a {{frozen
collection}} to decode {{frozen collection bytes}}
it can easily cause runtime error. eg. base has non-key column
{{frozen>}} as view's primary key. so {{tuple type}} is used to decode {{frozen}}
{{non-frozen-udt}} cannot be used as view's primary key. the issue here is
only use {{frozen-collection}}.
3. in {{sasi}}. haven't check how it is affected. will check it later
was (Author: jasonstack):
Some issues are related to {{ColumnMetadata.cellValueType()}} which currently :
{{a}}. if CollectionType, returns value's type; {{b}} otherwise, its own type.
It doesn't handle properly: {{1}}. frozen collection type, {{2}}. non-frozen
udt which requires cellPath to retrieve value's type..
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-13573:
-
Component/s: Materialized Views
CQL
Core
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Core, CQL, Materialized Views, Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079806#comment-16079806
]
ZhaoYang edited comment on CASSANDRA-13573 at 7/10/17 3:16 AM:
---
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13573] |
[unit|https://circleci.com/gh/jasonstack/cassandra/124] | dtest |
changes:
1. use {{type.toJSONString()}} with {{json.writeRawValue()}} instead of
{{type.getString()}} to generate readable content
2. {{column.cellValueType}} now : {{a}}. if non-frozen collection, return
value type, {{b}}. otherwise, return column type.
going to add more dtests on sstabledump, MV and SASI.
was (Author: jasonstack):
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13573] |
[unit|https://circleci.com/gh/jasonstack/cassandra/124] | dtest |
changes:
1. use {{type.toJSONString()}} with {{json.writeRawValue()}} instead of
{{type.getString()}} to generate readable content
2. {{column.cellValueType}} now : {{a}}. if non-frozen collect, return value
type, {{b}}. otherwise, return current column type.
going to add more dtests on sstabledump, MV and SASI.
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Core, CQL, Materialized Views, Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13573) sstabledump doesn't print out tombstone information for frozen set collection
[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079806#comment-16079806
]
ZhaoYang commented on CASSANDRA-13573:
--
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13573] |
[unit|https://circleci.com/gh/jasonstack/cassandra/124] | dtest |
changes:
1. use {{type.toJSONString()}} with {{json.writeRawValue()}} instead of
{{type.getString()}} to generate readable content
2. {{column.cellValueType}} now : a. only if non-frozen collect
going to add more dtests on Dump, MV and SASI.
> sstabledump doesn't print out tombstone information for frozen set collection
> -
>
> Key: CASSANDRA-13573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13573
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefano Ortolani
>Assignee: ZhaoYang
>
> Schema and data"
> {noformat}
> CREATE TABLE ks.cf (
> hash blob,
> report_id timeuuid,
> subject_ids frozen,
> PRIMARY KEY (hash, report_id)
> ) WITH CLUSTERING ORDER BY (report_id DESC);
> INSERT INTO ks.cf (hash, report_id, subject_ids) VALUES (0x1213, now(),
> {1,2,4,5});
> {noformat}
> sstabledump output is:
> {noformat}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1213" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 16,
> "clustering" : [ "ec01eed0-49d9-11e7-b39a-97a96f529c02" ],
> "liveness_info" : { "tstamp" : "2017-06-05T10:29:57.434856Z" },
> "cells" : [
> { "name" : "subject_ids", "value" : "" }
> ]
> }
> ]
> }
> ]
> {noformat}
> While the values are really there:
> {noformat}
> cqlsh:ks> select * from cf ;
> hash | report_id| subject_ids
> +--+-
> 0x1213 | 02bafff0-49d9-11e7-b39a-97a96f529c02 | {1, 2, 4}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa reassigned CASSANDRA-13653:
--
Assignee: Chandan Kumar Agarwal
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Chandan Kumar Agarwal
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for investigating bug reports.
> Some good places to start:
> - CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
> Restrictions
> Some packages not to worry about:
> - Deep internals that don't already have them
> (org.apache.cassandra.db.rows/partitions/etc)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079526#comment-16079526
]
Robert Stupp commented on CASSANDRA-10786:
--
Looks mostly good to me, but the patch breaks LWTs and prepared {{LIST}}
statements.
* Added fixes to the review branch:
https://github.com/ifesdjeen/cassandra/compare/10786-trunk-rebase...snazy:10786-trunk-review
* Added some minor wording changes in protocol spec.
* Added new utest to validate prepared {{LIST}} statements and prepared LWTs
* Fixes for the prepared LIST/LWT statements required some logic changes in
{{ResultSet.Codec.encode}}, {{ExecuteMessage}} and removal of an assertion in
the Java driver. Java driver patch:
https://github.com/datastax/java-driver/compare/java1196-new...snazy:java1196-review
(Note: I've no clue whether someone actually prepares a {{LIST}} statement, but
it's possible)
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 4.x
>
>
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to
> the prepared statement id. If it doesn't match the current one on the server,
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated
> result metadata (this overrides the {{No_metadata}} flag, even if the client
> had requested it)
> - the client updates its copy of the result metadata before it decodes the
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry,
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456)
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false,
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079472#comment-16079472
]
Varun Barala commented on CASSANDRA-13653:
--
[~agacha] You don't need to request just assign it to yourself and provide a
patch.
* Reviewers will review the patch
* Committers will commit it
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for investigating bug reports.
> Some good places to start:
> - CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
> Restrictions
> Some packages not to worry about:
> - Deep internals that don't already have them
> (org.apache.cassandra.db.rows/partitions/etc)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079468#comment-16079468
]
Chandan Kumar Agarwal commented on CASSANDRA-13653:
---
Hi I am new to open source contribution.I am following this link as guide to
contributing to Cassandra https://wiki.apache.org/cassandra/HowToContribute .I
want to work on this issue but I can find assign button to assign this to
myself. Do I need to request any access for this?
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for investigating bug reports.
> Some good places to start:
> - CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
> Restrictions
> Some packages not to worry about:
> - Deep internals that don't already have them
> (org.apache.cassandra.db.rows/partitions/etc)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
