jasonmp85
commented
9 years ago Quoting your mailing list post:
We have some triggers that run on INSERT, DELETE, and UPDATE (for a specific column value) of one of our biggest tables (the primary target for sharding). It is critical that these triggers still function when writing into the distributed tables. One caveat, however, is that it would be a burden for the trigger to fire multiple times in the case of a replicated shard. We are using these triggers as a way to track necessary updates to another datastore based on specific conditions.
In your particular case, which would be most desirable:
- Triggers are propagated to worker shards and take action locally on each shard
- The master node evaluates the trigger and takes some action after a successful modification to a distributed table
This is a pretty big feature space, so details will help us evaluate feasibility in the future.
Additionally: You said your triggers run after a successful modification. What do they do? Are they writing to some other table? Enqueuing a job? If they do write to another table, would you need that table to be distributed as well?
It would be nice if triggers associated with a table were automatically propagated across all databases when the table sharding occurs. Perhaps it could be an optional flag, as I could envision scenarios where this might be undesirable.