Thank you everyone, then I will skip triggers. Bernardo Botella <conta...@bernardobotella.com> 于2025年2月1日周六 07:01写道:
> +1 on skipping triggers if we can’t make sure that it will work in every > scenario. > The experience of copying a table and having a broken result is definitely > something to avoid. > > Kind regards, > Bernardo > > > On Jan 31, 2025, at 10:49 AM, Brandon Williams <dri...@gmail.com> wrote: > > > > I agree, and triggers are an expert feature anyway so I wouldn't > > expect them to be copied. > > > > Kind Regards, > > Brandon > > > > On Fri, Jan 31, 2025 at 12:46 PM Štefan Miklošovič > > <smikloso...@apache.org> wrote: > >> > >> 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. > >