Yes, you are right. In the "example", what is parsed from the configuration file is the keyspace name and table name of an auditing table where all partition updates for the respective table will be persisted.
However, still, I would not support that. The reasoning behind that is that as soon as there is an interface users can code against and they put a jar on the class path, we are opening proverbial can of worms: Also, consider this scenario, not necessarily 100% related to "copying tables" but anyway: 1) implement a trigger and put it on the class path 2) create keyspace and table 3) create trigger on that table 4) insert data 5) create another table (e.g. by copying, but does not matter) 5) drop trigger from 3) on table 2) (by cql) 6) stop node, remove trigger jar from class path 7) start node 8) node fails to start (I have tested this). Why? Because as it was replaying all epochs from 0, it encountered trigger creation from 3), but that trigger is not on the class path anymore! If there are 1000 epochs and we drop a trigger in epoch 5, we still need that very same trigger implementation in epoch 1000. We just can not get rid of that. 2) As soon as it is custom, we do not have control over what it does. It might be true that in this and that particular case of that "example" it is safe to use, but can we say it is _always safe_? What if a user is not aware of the consequences and then they copy a table with a trigger which either does not work how they were thinking it will be or it just fails? For that reason, I would also forbid "custom indexes". All index implementations except SAI and legacy 2i should be banned when doing coping like that. If people want to have their custom indexes on a copied table, they can still create it by hand. I don't see anything wrong with that. In general I think we should be very cautious about this and not support it if we just can't say that it will all work in 100% of scenarios. On Mon, Feb 3, 2025 at 6:14 PM Abe Ratnofsky <a...@aber.io> wrote: > I think it would be reasonable to copy the triggers. The ITrigger > interface provides a Partition with metadata() to find which table the > original mutation was issued for. In the example AuditTrigger, the > destination audit table is configurable but if a user attaches AuditTrigger > to an existing table then clones that table, writes to both tables would be > audited in the same destination audit table, and AuditTrigger is explicitly > designed to handle that.
