Thank you Maxwell for reaching ML with this. I was talking to Maxwell about a feature where CREATE TABLE LIKE would also support triggers.
create table ks.tb_copy like ks.tb with triggers "with triggers" would be added to CQL grammar and it would "copy" what that trigger(s) is / are doing. While this is technically possible to do, I am not completely sure it is the right thing to do. If you take a look into examples/triggers (we have this dir in the repository), there is an example of a trigger which is parsing keyspace / table to operate on from the configuration file (examples/triggers/conf/AuditTrigger.properties). If a user copies a table like this, then, sure, a trigger will be copied as well, but it will not match anymore. My argument against supporting copying triggers is that when we can not guarantee that it will work _in all cases_, then I would say that we should not be supporting this. On Fri, Jan 31, 2025 at 6:06 PM guo Maxwell <cclive1...@gmail.com> wrote: > Hello dev, > I'm very sorry to disturb everyone's wonderful weekend time. Please > allow me to ask about the trigger in Cassandra? > Maybe everyone knows some implementations of Cassandra's trigger. If the > user needs it to do something, it may be > necessary to package the jar we need and load the corresponding class to > do something similar to preprocessing on the write path. > So my question here is : Are we fine with the current implementation here, > Should we support triggers in new features ? > I encountered this problem recently, we are also discussing whether we > need to continue to support trigger's clone in CEP-43 (CREATE TABLE LIKE)? > > Looking forward to your reply. >
