@Sujanadh made some great points that in order to facilitate this we will need:

• To remove the foreign key relation for task_events.user_id, from both the fmtm_schema.sql init SQL and via a migration.
• To add the username and profile_img fields directly to the task_events table, in a migration and fmtm_schema.sql file again.
• Update the models + SQL to no longer dynamically get the username / profile_img on read, but instead they should be inserted with the task event on write.

This way we can keep the task event record without actually having to link to an existing user.

However, we should first clarify if we need to keep this info, or if we should wipe it and simply show:
username: deleted
profile_img: a stock photo

Update to the above!

I don't think we should remove the user_id foreign key from task_events, as referential integrity is important and it allows us to easily join tables.

Instead we should update the foreign key to use ON DELETE RESTRICT, which means we can delete the user, but still keep rows that reference the user.

From the postgresql docs: RESTRICT prevents deletion of a referenced row. NO ACTION means that if any referencing rows still exist when the constraint is checked, an error is raised; this is the default behavior if you do not specify anything.

Please give this option a test 👍