Hi Maxwell, even the issues mentioned in CASSANDRA-20287 are fixed, I still do not think we should support the copying of triggers. Reasons I think we should not support that are:
1) According to this comment (1) Triggers API is considered beta and can change. Unless we promote trigger's API out of beta state, I do not think we should build anything on top of that and integrate it deeper with the rest of the codebase, as CASSANDRA-19965 patch would do. 2) What the fix in CASSANDRA-20287 would do is to prevent the cases when trigger implementation is not on the class path anymore and a node is restarted. For now, it would just fail to start. The fix would enable it to start even if it is not present. This is different from supporting copying triggers as such. The fact we just did not fail a node to start does not mean that we are embracing triggers as a whole. 3) Even if we supported copying of a trigger between tables, since its implementation is outside of our control, such a trigger might contain arbitrary logic, which might be applicable for the source table but its behavior would not be desirable for the other. The implementation of a trigger might be so that there might be logic specifically wired for the source table and when applied to a target table, it would stop behaving correctly. For example, if a trigger is processing Partition inside its "augment" method, and it is coded in such a way that it is specifically processing specific columns, what would happen if a target table altered its schema after we copy it (e.g. by adding or removing columns) while this trigger would be active? And so on, and so on ... (1) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/triggers/ITrigger.java#L37-L39 On Mon, Feb 10, 2025 at 10:22 AM guo Maxwell <cclive1...@gmail.com> wrote: > Referring to the opinions of most people, we ignore the cloning of > triggers just for the CREATE TABLE LIKE feature. > > guo Maxwell <cclive1...@gmail.com> 于2025年2月10日周一 16:39写道： > >> Then we don’t support trigger until CASSANDRA-20287 is fixed, and this >> rule applies to custom index , too. right ? >> >> >> Sam Tunnicliffe <s...@beobal.com> 于2025年2月5日周三 01:24写道： >> >>> This is really a bug with the current implementation of >>> CreateTriggerStatement and I've filed CASSANDRA-20287 to address it. >>> >>> Thanks, >>> Sam >>> >>> > On 3 Feb 2025, at 21:06, Štefan Miklošovič <smikloso...@apache.org> >>> wrote: >>> > >>> > Correct, snapshotting is the way to go here via nodetool cms snapshot >>> > >>> > But, you see? One more "problem" ... I bet my boots that in the >>> majority of cases this will be forgotten. Then we would need to put that >>> JAR back just to boot the cluster for the sake of snapshotting it. >>> > >>> > On Mon, Feb 3, 2025 at 9:58 PM Abe Ratnofsky <a...@aber.io> wrote: >>> > AFAIK the TCM replay issue you're describing (something is created and >>> dropped during replay, fails if can't create) applies to custom types and a >>> few other things, and one way around it is CMS snapshotting so replay >>> doesn't start at epoch 0; it wouldn't be safe to remove the trigger from >>> the classpath until the trigger drop epoch has been included in a snapshot: >>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-SnapshottingMetadataLog >>> > >>> > I also think it's reasonable to not include triggers (or other custom >>> fields) in the clone, but if users need to sort out what parts of their >>> original table were copied to their clone it's not as convenient to have a >>> separate command for it. >>> >>>
