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. >> >>
