Hi Stefan , Yes ,you are right, That is why I send the second email stating that we are not going to support cloning triggers in CREATE TABLE LIKE .
Štefan Miklošovič <smikloso...@apache.org> 于2025年2月10日周一 18:12写道： > 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. >>>> >>>>
