[v11] onDelete: CASCADE on reply note

[sftblw]

💡 Summary

When some note deletes, attached replies are deleted too.

code

	@ManyToOne(type => Note, {
		onDelete: 'CASCADE'
	})
	@JoinColumn()
	public reply: Note | null;

🙂 Expected Behavior

deleted notes should be displayed as (deleted) and should not affect replies (should not do cascade deletion)

☹️ Actual Behavior

whether it is remote or not, notes replying to deleted all deletes by cascading.

📝 Steps to Reproduce

1. make a note A
2. reply to a note A = B
3. delete A
4. B is deleted.

📌 Environment

v11

v10 does well

[tamaina]

I have heard that @syuilo says that this is a feature.

[sftblw]

@tamaina If It is really so please mark this issue as closed

[acid-chicken]

FYI: https://github.com/syuilo/misskey/pull/4572#issuecomment-478474515 and below. (I'm sorry about that discussed them in Japanese!)

[syuilo]

The soft deletion was postponed because the implementation was difficult. It may be implemented in the future.

[ghost]

This is one of Misskey's most annoying behaviors, please do fix this sooner rather than later.

[rinsuki]

あとリプライ先のユーザーIDなどを非正規化していて、それらはリプライ先が削除されたとしてもNULLになったりしないので何らかの検索処理などで不具合が発生したりしそう それらのことを考えるといっそリプライ自体も削除した方が良いのではないかという考えです 私もできれば現在のようにリプライ自体は残して、リプライ先を（削除された投稿）のようにしたいですが、手間をかけてまでそれを実現しようとしなくてもいいのかなと 一応手間をかけてそれを実現する方法としては、replyIdとは別にisReplyのようなプロパティを別途保存しておくとか...

リプライ先のユーザーIDをisReply代わりにすれば全てが解決したりしませんか？user消された時のこと考えるとちょっと微妙か

[Sayamame-beans]

リプライ/引用がCASCADEで削除されるのはMisskey固有の挙動と聞きました。 個人的には、元投稿が消えることで巻き込まれて消えるのは少し微妙に感じます。 (例: 有用なノートが引用/リプライ先に繋がっていても、元投稿のユーザーがノート/アカウントを削除すると一緒に消えてしまう)

また、元投稿とリプ/引用をしたユーザーが異なると、他ユーザーの投稿を(ある意味で)勝手に消せることになります… (例: 他ユーザーからの都合の悪いリプ/引用が付いた場合に消して無かったことに出来てしまう)