Matthias Broecheler created CASSANDRA-10546: -----------------------------------------------
Summary: Custom MV support Key: CASSANDRA-10546 URL: https://issues.apache.org/jira/browse/CASSANDRA-10546 Project: Cassandra Issue Type: New Feature Reporter: Matthias Broecheler The MV implementation should be generalized to allow for custom materialized view implementations. Like with MV, the logic would be triggered by a mutation to some base table on which the custom MV is registered. A custom MV would allow for custom logic to determine the "derived" mutations that need to be applied as a result of the base table mutation. It would then ensure that those derived mutations are applied (to other tables) as the current MV implementation does. Note, that a custom MV implementation is responsible for ensuring that any tables that derived mutations are written into exist. As such, a custom MV implementation has an initialization logic which can create those tables upon registration if needed. There should be no limit on what table a custom MV can write derived records to (even existing ones). Example: (Note, that this example is somewhat construed for simplicity) We have a table in which we track user visits to certain properties with timestamp: {code} CREATE TABLE visits ( userId bigint, visitAt timestamp, property varchar, PRIMARY KEY (userId, visitAt) ); {code} Every time a user visits a property, a record gets added to this table. Records frequently come in out-of-order. At the same time, we would like to know who is currently visiting a particular property (with their last entry time). For that, we create a custom MV registered against the {{visits}} table which upon registration creates the following table: {code} CREATE TABLE currentlyVisiting ( property varchar, userId bigint, enteredOn timestamp, PRIMARY KEY (property, userId) ); {code} Now, when a record (u,v,p) gets inserted into the {{visits}} table the custom MV logic gets invoked: # It reads the most recent visit record for user u: (u,v',p'). # If no such record exists, it emits (p,u,v) targeting table {{currentlyVisiting}} as a derived record to be persisted. # If such a record exists and v'>=v then it emits nothing. But if v'<v it emits records (p',u,v') to be deleted and (p,u,v) to be added to table {{currentlyVisiting}}. The MV framework ensures that the emitted records get persisted correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)