[ https://issues.apache.org/jira/browse/CASSANDRA-10546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999065#comment-14999065 ]
Jon Haddad commented on CASSANDRA-10546: ---------------------------------------- Would CASSANDRA-8844 cover what you need here? It seems like all you're really looking to do is be notified of underlying mutations. > 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)