You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Wenjun (JIRA)" <ji...@apache.org> on 2010/11/12 04:45:13 UTC
[jira] Created: (CASSANDRA-1734) New subcolumn resurrect deleted
subcolumns
New subcolumn resurrect deleted subcolumns
------------------------------------------
Key: CASSANDRA-1734
URL: https://issues.apache.org/jira/browse/CASSANDRA-1734
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7 beta 3
Environment: Windows7-64
Reporter: Wenjun
The followings are the conversation I had with jbellis on IRC:
have a question on deletion of super column....deletion of SuperColumn works fine....but when I add any new sub-column, the 'old' sub-columns reappear..how can I tell they are tombstoned
the 'old' sub-columns still have all the data in place, including timestamp
and the timestamp is older than markDeletaAt of the super column
<jbellis> appoji: right. that is expected. the subcolumns won't be tombstoned, the supercolumn tombstone should supress them.
<jbellis> shouldn't*
<jbellis> appoji: but writing a new subcolumn should resurrect the others. can you submit a test case?
I am able to reproduce it with cli as followings:
1. create column family UserGroup with column_type = 'Super' and gc_grace=5 and comparator = 'AsciiType' and subcomparator = 'BytesType'
2. set UserGroup ['100'] ['memberList']['paul']=''
3. del UserGroup ['100'] ['memberList']
4. wait for 5 seconds and "list UserGroup" does not return any data, which is correct
5. set UserGroup ['100'] ['memberList']['andrew']=''
6. now "list UserGroup" returns 2 sub-columns ('paul' and 'andrew')
here is server log for step 6:
DEBUG 22:40:52,378 range_slice
DEBUG 22:40:52,379 RangeSliceCommand{keyspace='Appoji', column_family='UserGroup
1', super_column=null, predicate=SlicePredicate(slice_range:SliceRange(start:80
01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 28
0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47 72 6F 75 70 31 00 0C 00 02 0C 00 0
2 0B 00 01 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 6
5 5F 73 6C 69 63 65 73 00 00 00 28 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47
72 6F 75 70 31 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00, r
eversed:false, count:100)), range=[0,0], max_keys=100}
DEBUG 22:40:52,380 restricted single token match for query [0,0]
DEBUG 22:40:52,381 local range slice
DEBUG 22:40:52,382 collecting 0 of 100: SuperColumn(memberList -delete at 128953
3231194000- [616e64726577:false:0@1289533250404000,7061756c:false:0@128953321401
5000,])
DEBUG 22:40:52,383 scanned DecoratedKey(9839004666223652184852086760848439587, 3
13030)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1734) New subcolumn resurrect deleted
subcolumns
Posted by "T Jake Luciani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
T Jake Luciani updated CASSANDRA-1734:
--------------------------------------
Attachment: 1734_v2.txt
The patch doesn't account for already deleted rows, where cf if null.
I've addressed this in the next patch, +1 with this change.
> New subcolumn resurrect deleted subcolumns
> ------------------------------------------
>
> Key: CASSANDRA-1734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1734
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7 beta 3
> Environment: Windows7-64
> Reporter: Wenjun
> Assignee: Jonathan Ellis
> Fix For: 0.7.0
>
> Attachments: 1734.txt, 1734_v2.txt
>
>
> The followings are the conversation I had with jbellis on IRC:
> have a question on deletion of super column....deletion of SuperColumn works fine....but when I add any new sub-column, the 'old' sub-columns reappear..how can I tell they are tombstoned
> the 'old' sub-columns still have all the data in place, including timestamp
> and the timestamp is older than markDeletaAt of the super column
> <jbellis> appoji: right. that is expected. the subcolumns won't be tombstoned, the supercolumn tombstone should supress them.
> <jbellis> shouldn't*
> <jbellis> appoji: but writing a new subcolumn should resurrect the others. can you submit a test case?
> I am able to reproduce it with cli as followings:
> 1. create column family UserGroup with column_type = 'Super' and gc_grace=5 and comparator = 'AsciiType' and subcomparator = 'BytesType'
> 2. set UserGroup ['100'] ['memberList']['paul']=''
> 3. del UserGroup ['100'] ['memberList']
> 4. wait for 5 seconds and "list UserGroup" does not return any data, which is correct
> 5. set UserGroup ['100'] ['memberList']['andrew']=''
> 6. now "list UserGroup" returns 2 sub-columns ('paul' and 'andrew')
> here is server log for step 6:
> DEBUG 22:40:52,378 range_slice
> DEBUG 22:40:52,379 RangeSliceCommand{keyspace='Appoji', column_family='UserGroup
> 1', super_column=null, predicate=SlicePredicate(slice_range:SliceRange(start:80
> 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 28
> 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47 72 6F 75 70 31 00 0C 00 02 0C 00 0
> 2 0B 00 01 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 6
> 5 5F 73 6C 69 63 65 73 00 00 00 28 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47
> 72 6F 75 70 31 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00, r
> eversed:false, count:100)), range=[0,0], max_keys=100}
> DEBUG 22:40:52,380 restricted single token match for query [0,0]
> DEBUG 22:40:52,381 local range slice
> DEBUG 22:40:52,382 collecting 0 of 100: SuperColumn(memberList -delete at 128953
> 3231194000- [616e64726577:false:0@1289533250404000,7061756c:false:0@128953321401
> 5000,])
> DEBUG 22:40:52,383 scanned DecoratedKey(9839004666223652184852086760848439587, 3
> 13030)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1734) New subcolumn resurrect deleted
subcolumns
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1734:
--------------------------------------
Reviewer: tjake (was: gdusbabek)
> New subcolumn resurrect deleted subcolumns
> ------------------------------------------
>
> Key: CASSANDRA-1734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1734
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7 beta 3
> Environment: Windows7-64
> Reporter: Wenjun
> Assignee: Jonathan Ellis
> Fix For: 0.7.0
>
> Attachments: 1734.txt
>
>
> The followings are the conversation I had with jbellis on IRC:
> have a question on deletion of super column....deletion of SuperColumn works fine....but when I add any new sub-column, the 'old' sub-columns reappear..how can I tell they are tombstoned
> the 'old' sub-columns still have all the data in place, including timestamp
> and the timestamp is older than markDeletaAt of the super column
> <jbellis> appoji: right. that is expected. the subcolumns won't be tombstoned, the supercolumn tombstone should supress them.
> <jbellis> shouldn't*
> <jbellis> appoji: but writing a new subcolumn should resurrect the others. can you submit a test case?
> I am able to reproduce it with cli as followings:
> 1. create column family UserGroup with column_type = 'Super' and gc_grace=5 and comparator = 'AsciiType' and subcomparator = 'BytesType'
> 2. set UserGroup ['100'] ['memberList']['paul']=''
> 3. del UserGroup ['100'] ['memberList']
> 4. wait for 5 seconds and "list UserGroup" does not return any data, which is correct
> 5. set UserGroup ['100'] ['memberList']['andrew']=''
> 6. now "list UserGroup" returns 2 sub-columns ('paul' and 'andrew')
> here is server log for step 6:
> DEBUG 22:40:52,378 range_slice
> DEBUG 22:40:52,379 RangeSliceCommand{keyspace='Appoji', column_family='UserGroup
> 1', super_column=null, predicate=SlicePredicate(slice_range:SliceRange(start:80
> 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 28
> 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47 72 6F 75 70 31 00 0C 00 02 0C 00 0
> 2 0B 00 01 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 6
> 5 5F 73 6C 69 63 65 73 00 00 00 28 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47
> 72 6F 75 70 31 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00, r
> eversed:false, count:100)), range=[0,0], max_keys=100}
> DEBUG 22:40:52,380 restricted single token match for query [0,0]
> DEBUG 22:40:52,381 local range slice
> DEBUG 22:40:52,382 collecting 0 of 100: SuperColumn(memberList -delete at 128953
> 3231194000- [616e64726577:false:0@1289533250404000,7061756c:false:0@128953321401
> 5000,])
> DEBUG 22:40:52,383 scanned DecoratedKey(9839004666223652184852086760848439587, 3
> 13030)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1734) New subcolumn resurrect deleted
subcolumns
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1734:
--------------------------------------
Attachment: 1734.txt
patch to add removeDeleted call to getRangeSlices (list) as it is for getColumnFamily (get)
> New subcolumn resurrect deleted subcolumns
> ------------------------------------------
>
> Key: CASSANDRA-1734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1734
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7 beta 3
> Environment: Windows7-64
> Reporter: Wenjun
> Attachments: 1734.txt
>
>
> The followings are the conversation I had with jbellis on IRC:
> have a question on deletion of super column....deletion of SuperColumn works fine....but when I add any new sub-column, the 'old' sub-columns reappear..how can I tell they are tombstoned
> the 'old' sub-columns still have all the data in place, including timestamp
> and the timestamp is older than markDeletaAt of the super column
> <jbellis> appoji: right. that is expected. the subcolumns won't be tombstoned, the supercolumn tombstone should supress them.
> <jbellis> shouldn't*
> <jbellis> appoji: but writing a new subcolumn should resurrect the others. can you submit a test case?
> I am able to reproduce it with cli as followings:
> 1. create column family UserGroup with column_type = 'Super' and gc_grace=5 and comparator = 'AsciiType' and subcomparator = 'BytesType'
> 2. set UserGroup ['100'] ['memberList']['paul']=''
> 3. del UserGroup ['100'] ['memberList']
> 4. wait for 5 seconds and "list UserGroup" does not return any data, which is correct
> 5. set UserGroup ['100'] ['memberList']['andrew']=''
> 6. now "list UserGroup" returns 2 sub-columns ('paul' and 'andrew')
> here is server log for step 6:
> DEBUG 22:40:52,378 range_slice
> DEBUG 22:40:52,379 RangeSliceCommand{keyspace='Appoji', column_family='UserGroup
> 1', super_column=null, predicate=SlicePredicate(slice_range:SliceRange(start:80
> 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 28
> 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47 72 6F 75 70 31 00 0C 00 02 0C 00 0
> 2 0B 00 01 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 6
> 5 5F 73 6C 69 63 65 73 00 00 00 28 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47
> 72 6F 75 70 31 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00, r
> eversed:false, count:100)), range=[0,0], max_keys=100}
> DEBUG 22:40:52,380 restricted single token match for query [0,0]
> DEBUG 22:40:52,381 local range slice
> DEBUG 22:40:52,382 collecting 0 of 100: SuperColumn(memberList -delete at 128953
> 3231194000- [616e64726577:false:0@1289533250404000,7061756c:false:0@128953321401
> 5000,])
> DEBUG 22:40:52,383 scanned DecoratedKey(9839004666223652184852086760848439587, 3
> 13030)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1734) New subcolumn resurrect deleted
subcolumns
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1734:
--------------------------------------
Priority: Minor (was: Major)
Affects Version/s: (was: 0.7 beta 3)
0.7 beta 1
> New subcolumn resurrect deleted subcolumns
> ------------------------------------------
>
> Key: CASSANDRA-1734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1734
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7 beta 1
> Environment: Windows7-64
> Reporter: Wenjun
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments: 1734.txt, 1734_v2.txt
>
>
> The followings are the conversation I had with jbellis on IRC:
> have a question on deletion of super column....deletion of SuperColumn works fine....but when I add any new sub-column, the 'old' sub-columns reappear..how can I tell they are tombstoned
> the 'old' sub-columns still have all the data in place, including timestamp
> and the timestamp is older than markDeletaAt of the super column
> <jbellis> appoji: right. that is expected. the subcolumns won't be tombstoned, the supercolumn tombstone should supress them.
> <jbellis> shouldn't*
> <jbellis> appoji: but writing a new subcolumn should resurrect the others. can you submit a test case?
> I am able to reproduce it with cli as followings:
> 1. create column family UserGroup with column_type = 'Super' and gc_grace=5 and comparator = 'AsciiType' and subcomparator = 'BytesType'
> 2. set UserGroup ['100'] ['memberList']['paul']=''
> 3. del UserGroup ['100'] ['memberList']
> 4. wait for 5 seconds and "list UserGroup" does not return any data, which is correct
> 5. set UserGroup ['100'] ['memberList']['andrew']=''
> 6. now "list UserGroup" returns 2 sub-columns ('paul' and 'andrew')
> here is server log for step 6:
> DEBUG 22:40:52,378 range_slice
> DEBUG 22:40:52,379 RangeSliceCommand{keyspace='Appoji', column_family='UserGroup
> 1', super_column=null, predicate=SlicePredicate(slice_range:SliceRange(start:80
> 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 28
> 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47 72 6F 75 70 31 00 0C 00 02 0C 00 0
> 2 0B 00 01 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 6
> 5 5F 73 6C 69 63 65 73 00 00 00 28 0C 00 01 0B 00 03 00 00 00 0A 55 73 65 72 47
> 72 6F 75 70 31 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00, r
> eversed:false, count:100)), range=[0,0], max_keys=100}
> DEBUG 22:40:52,380 restricted single token match for query [0,0]
> DEBUG 22:40:52,381 local range slice
> DEBUG 22:40:52,382 collecting 0 of 100: SuperColumn(memberList -delete at 128953
> 3231194000- [616e64726577:false:0@1289533250404000,7061756c:false:0@128953321401
> 5000,])
> DEBUG 22:40:52,383 scanned DecoratedKey(9839004666223652184852086760848439587, 3
> 13030)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.