[
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)
