I have refactored the schema to include cascade on delete and cascade on update for kitchens. This will delete all food related to a kitchen when that kitchen is deleted.
The user is more complex. Since we have multiple users on one kitchen, it may be easier to force the user to 'leave' aka, remove all kitchen relations before allowing them to delete their account. Otherwise, if we setup cascades, one kitchen member could delete their account and that would delete any kitchens they were a part of which is not ideal.
At the moment, the user cannot delete their account without first deleting all of their kitchens.
I have added the delete endpoints, controller, and models for all entitites.
I have also refactored some of the constructor methods to return the item that has been created/deleted/patched as a response. This will be useful on the front end, and it's also much clearer to see what's going on when debugging.
I have refactored the schema to include cascade on delete and cascade on update for kitchens. This will delete all food related to a kitchen when that kitchen is deleted.
The user is more complex. Since we have multiple users on one kitchen, it may be easier to force the user to 'leave' aka, remove all kitchen relations before allowing them to delete their account. Otherwise, if we setup cascades, one kitchen member could delete their account and that would delete any kitchens they were a part of which is not ideal.
At the moment, the user cannot delete their account without first deleting all of their kitchens.
I have added the delete endpoints, controller, and models for all entitites. I have also refactored some of the constructor methods to return the item that has been created/deleted/patched as a response. This will be useful on the front end, and it's also much clearer to see what's going on when debugging.