Hey @U7ERLH6JX 🙂 there's no built-in way to perform a cascade delete like this. However, unless the cascade is massive, doing it within a single transaction function is probably the simplest approach

Thanks for the info @U899JBRPF! Will continue with the current approach! Out of curiousitly what would be classified as "massive" 😛 ? Mine could be 10s of thousands of tiny docs (log lines) at the worst case.

i have a m:n:p relation going on. n = 10m and p = 5k n. Thats the kind of average numbers i have. this was quite nice to do in a RDBMS but pretty much everything else I'd rather use XT 😆

"Massive" depends on your transaction throughput tolerances and how long you might be prepared to hog the transaction writer for exclusively to run the procedure as a singe atomic tx. You could always break the delete ops into more granular transactions if that is a concern, but then you have to think about scheduling/retrying/userspace-locking etc.

Mainstream RDBMSs 'complect' a tonne of stuff, but undoubtedly they do offer some pretty handy features/machinery

I use custom tx functions for doing deep deletions like this--if :as have :bs have :cs, c's delete tx fn deletes the c, b's deletes the b and any dependent cs, and so on

wherever appropriate the "higher" deletion is defined in terms of the "lower" deletion to keep it DRY

some single deletion actions end up creating txs with 1000s of xt delete ops but that doesn't seem to have been an issue so far so I agree with @U899JBRPF that aiming for a single tx if at all possible is the way to go

here's https://github.com/lgessler/glam/blob/master/src/main/glam/xtdb/token_layer.clj#L148 if you're curious--I'm using some custom helper functions but I hope it's somewhat legible. note I'm using a convention where if a function returns a valid xtdb transaction it ends in **, and if it returns a valid xtdb operation it ends in *

Great info! Thanks a lot @U899JBRPF @U49U72C4V 🙏