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.

Reply via email to