discourse

History

Kane York 10ddb8a9c4 FIX: Use destroy_all instead of delete_all for shared drafts Rails has an odd behavior for calling .delete_all on a has_many relation - the default behavior is to nullify the foreign key fields instead of actually 'DELETE'ing the records. Additionally, publishing a shared draft topic creates a PostRevision that the NotifyPostRevision job picks up which is then promptly deleted. Use destroy_all when cleaning up the revisions and have the NotifyPostRevision job tolerate deleted PostRevision records. This takes a small performance hit (several SQL DELETEs instead of just one) but shouldn't be too much of an issue (high cardinalities range from 30-100).		2020-03-05 11:13:43 -08:00
..
concerns	DEV: enable frozen string literal on all files	2019-05-13 09:31:32 +08:00
onceoff	DEV: s/\$redis/Discourse\.redis (#8431 )	2019-12-03 10:05:53 +01:00
regular	FIX: Use destroy_all instead of delete_all for shared drafts	2020-03-05 11:13:43 -08:00
scheduled	FEATURE: limit number of notifications per user to 10,000	2020-02-24 11:42:50 +11:00
base.rb	PERF: avoid shelling to get hostname aggressively	2020-02-18 15:13:19 +11:00