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.
