[
https://issues.apache.org/jira/browse/CASSANDRA-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079644#comment-16079644
]
ZhaoYang edited comment on CASSANDRA-13573 at 7/10/17 3:08 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 result in runtime error. eg. base has non-key column
{{frozen<list<tuple<text,text>>}} as view's primary key. so {{tuple<text,
text> type}} is used to decode {{frozen<list>}}
{{non-frozen-udt}} cannot be used as view's primary key. the issue here is
only with {{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..
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<list<tuple<text,text>>}} as view's primary key. so {{tuple<text,
text> type}} is used to decode {{frozen<list>}}
{{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
> 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<set<int>>,
> 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
