delete triggers firing with on_conflict('replace')
I think you might be confusing triggers with the `ON DELETE` behavior, which I don't believe falls under the same rules as triggers (recursive or otherwise). To avoid the issue, it should be sufficient to remove either the "on delete cascade" bit, or to disable the foreign_keys pragma.

I was able to replicate the behavior you've described using just the sqlite shell, so this definitely isn't a peewee issue. Whether it's a bug in sqlite is probably worth bringing up on the mailing list. Would there be a way to replace rows without deleting them first or is it necessary to disable `ON DELETE`/the `foreign_keys` pragma to avoid this problem? I'm not sure, that's a good question for the SQLite mailing list. It does seem like the combination of:

1. Pragma foreign_keys = on
2. On delete cascade
3. Insert or Replace

Can lead to rows in the related table being deleted.

An alternative, if you don't want to change the first 2, would be to execute a normal INSERT and then, if that fails with an IntegrityError, to do an update instead.
Hello.

I encountered this problem while inserting a new row, which violated a UNIQUE constraint, either through `Model.insert()` or `Model.insert_many()`. I didn't expect this behavior, since the [SQLite documentation](https://sqlite.org/lang_conflict.html) states that

> When the REPLACE conflict resolution strategy deletes rows in order to satisfy a constraint, delete triggers fire if and only if recursive triggers are enabled.

I doubled checked to see if `recursive_triggers` was disabled, but it doesn't even seem to be enabled by default.  Explicitly setting `recursive_triggers` by saying `db.pragma('recursive_triggers', 0, permanent=True)` also seems to have no effect. Is my understanding of SQLite wrong or would this be a bug on peewee's side? [Here](https://gist.github.com/Jovito/b2ad9a448a3d226d04c2d5b3c54d64b1) is an example.