[jira] [Updated] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated

2015-12-04 Thread Sam Tunnicliffe (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-9041:
---
Component/s: Local Write-Read Paths
 CQL

> Allow a PerRowSecondaryIndex to perform its index operation before the 
> underlying data has been mutated
> ---
>
> Key: CASSANDRA-9041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9041
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL, Local Write-Read Paths
>Reporter: Bryn Cooke
>Assignee: Sam Tunnicliffe
> Fix For: 3.0 beta 1
>
>
> The current PerRowSecondaryIndex receives its index event after the call to 
> BTree.update. This means that it is impossible to write an index that eagerly 
> removes stale index entries.
> It would be great to have some sort of preIndex method that gets called with 
> the key and column family.
> In addition a postIndex method that is guaranteed to get called regardless if 
> the actual BTree operation succeeds or not would allow cleanup in the event 
> of error. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated

2015-05-14 Thread Sam Tunnicliffe (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-9041:
---
Fix Version/s: (was: 2.2.x)
   3.0 beta 1

Moving this back to 3.0 as we're hoping to make it part of a wider overhaul of 
the 2i API (ticket to follow)

 Allow a PerRowSecondaryIndex to perform its index operation before the 
 underlying data has been mutated
 ---

 Key: CASSANDRA-9041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9041
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Bryn Cooke
Assignee: Sam Tunnicliffe
 Fix For: 3.0 beta 1


 The current PerRowSecondaryIndex receives its index event after the call to 
 BTree.update. This means that it is impossible to write an index that eagerly 
 removes stale index entries.
 It would be great to have some sort of preIndex method that gets called with 
 the key and column family.
 In addition a postIndex method that is guaranteed to get called regardless if 
 the actual BTree operation succeeds or not would allow cleanup in the event 
 of error. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated

2015-05-12 Thread Jonathan Ellis (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-9041:
--
Assignee: Sam Tunnicliffe

 Allow a PerRowSecondaryIndex to perform its index operation before the 
 underlying data has been mutated
 ---

 Key: CASSANDRA-9041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9041
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Bryn Cooke
Assignee: Sam Tunnicliffe

 The current PerRowSecondaryIndex receives its index event after the call to 
 BTree.update. This means that it is impossible to write an index that eagerly 
 removes stale index entries.
 It would be great to have some sort of preIndex method that gets called with 
 the key and column family.
 In addition a postIndex method that is guaranteed to get called regardless if 
 the actual BTree operation succeeds or not would allow cleanup in the event 
 of error. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated

2015-05-12 Thread Jonathan Ellis (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-9041:
--
Fix Version/s: 2.2.x

 Allow a PerRowSecondaryIndex to perform its index operation before the 
 underlying data has been mutated
 ---

 Key: CASSANDRA-9041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9041
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Bryn Cooke
Assignee: Sam Tunnicliffe
 Fix For: 2.2.x


 The current PerRowSecondaryIndex receives its index event after the call to 
 BTree.update. This means that it is impossible to write an index that eagerly 
 removes stale index entries.
 It would be great to have some sort of preIndex method that gets called with 
 the key and column family.
 In addition a postIndex method that is guaranteed to get called regardless if 
 the actual BTree operation succeeds or not would allow cleanup in the event 
 of error. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-9041) Allow a PerRowSecondaryIndex to perform its index operation before the underlying data has been mutated

2015-03-25 Thread Bryn Cooke (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryn Cooke updated CASSANDRA-9041:
--
Summary: Allow a PerRowSecondaryIndex to perform its index operation before 
the underlying data has been mutated  (was: Allow a PerRowSecondaryIndex to 
perform it's index operation before the underlying data has been mutated)

 Allow a PerRowSecondaryIndex to perform its index operation before the 
 underlying data has been mutated
 ---

 Key: CASSANDRA-9041
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9041
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Bryn Cooke

 The current PerRowSecondaryIndex receives its index event after the call to 
 BTree.update. This means that it is impossible to write an index that eagerly 
 removes stale index entries.
 It would be great to have some sort of preIndex method that gets called with 
 the key and column family.
 In addition a postIndex method that is guaranteed to get called regardless if 
 the actual BTree operation succeeds or not would allow cleanup in the event 
 of error. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)