Cascading deletes on foreign keys in recommended migrations

8 views
Skip to first unread message

Janko Marohnić

unread,
May 25, 2021, 1:59:20 PMMay 25
to Rodauth
Hi Jeremy,

I occasionally try to delete an account record from the console while testing, and most of the time it fails because there is an associated record with a foreign key referencing that account, blocking the deletion (usually a remember key record).

I wanted to ask, what do you think in general about setting `on_delete: :cascade` on foreign keys on Rodauth tables referencing the accounts table? If you think it's safe in general, would you accept a PR that updates the README to show setting `on_delete: :cascade`? Personally, that's how set up most of my foreign keys in applications I work on, as it often simplifies deletion in application code.

I'm thinking of adding this to rodauth-rails' Active Record migrations, but I try not to diverge too much from the recommended way. Alternatively, I'm already developing a module that would automatically define Active Record associations based on Rodauth configuration, so there I could set up `dependent: :destroy`. But I generally prefer doing it on the database level.

Kind regards,
Janko

Jeremy Evans

unread,
May 25, 2021, 2:10:04 PMMay 25
to rod...@googlegroups.com
I tend to avoid ON DELETE CASCADE because it becomes much easier to accidentally remove a whole bunch of data at once when using it.  It does make the common deletion case simpler, but I prefer the extra safety by default.  Also, I don't tend to do all that much deleting in my applications, so the lack of ON DELETE CASCADE doesn't affect me all that much.

That being said, I'm interested to hear what others think about this issue. If there is community consensus that we should switch to using  on_delete: :cascade, I not opposed to switching.  If we do switch, we should probably update the tests as well.  As far as I know, it shouldn't affect the tests since we don't delete the accounts or update the primary key value for them.

Thanks,
Jeremy
Reply all
Reply to author
Forward
0 new messages