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