> Remove <value1>.<pkX> AND Add <value2>.<pkX> such that if <value1>.<pkX> is > NOT found, the whole row will be scanned for <ANYvalue>.<pkX> and remove that > value instead. Couple of thoughts: * that sounds like something that would need a lock or transaction to stop changes when things were scanned. e.g. You would need the sort of key range lock you get from the SERIALIZABLE transaction isolation level in an ACID transaction. * it would make the write non idempotent * If node 1 has <value1>.<pkX> and node 2 did not they would apply the change differently. And node 1 could still have <AnyValue>.<px_id> while node 2 did not.
> as the index would always be consistent as well. Can you embrace the inconsistency ? Here is one approach cassandra will be taking https://issues.apache.org/jira/browse/CASSANDRA-2897 Discard the invalid entries on read and repair the problem. Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 12/09/2012, at 11:59 PM, "Hiller, Dean" <dean.hil...@nrel.gov> wrote: > Using wide rows for indexing is extremely common. I was wondering if we > could get some type of command like so for index rows > > Remove <value1>.<pkX> AND Add <value2>.<pkX> such that if <value1>.<pkX> is > NOT found, the whole row will be scanned for <ANYvalue>.<pkX> and remove that > value instead. This would rock for all those people using wide rows as > indices on a RF=3 with QUOROM writes and reads as the index would always be > consistent as well. > > The above situation can occur frequently in some systems and it would just be > nice for it not to happen with QUOROM and RF=3 is all. > > Maybe I should just file a ticket and if it ever picks up enough votes, the > community might consider implementing it? > > Thoughts? > > Dean
