Deleting Calendars Leaves Behind Database Entries

[DevynCJohnson]

Baikal version: 0.9.2

Expected behavior: When deleting all calendars from all users and deleting all users, I would expect the database tables calendarinstances, calendars, and calendarchanges

Current behavior: The database tables calendarinstances, calendars, and calendarchanges still contain entries.

Steps to reproduce:

1. Delete all calendars of all users
2. Delete all users
3. Look in the the about listed database tables

Also, why does the database (in MySQL) not utilize foreign keys?

[kattelk]

Commenting to show that this problem is affecting others. I have also seen this problem. Is this related to #1048?

[nicokaiser]

Since SabreDAV does not seem to use foreign keys in the database (please correct me if this is wrong), orphaned entries are not deleted.

For example: when deleting a calendar through the frontend, only the calendar instance is deleted. As the calendar then does not have any name or principal anymore, it is orphaned and cannot be accessed (nor deleted through the admin interface).

-- Orphaned calendars (without instances)
SELECT calendars.* FROM calendars
LEFT JOIN calendarinstances ON calendarinstances.calendarid = calendars.id
WHERE calendarinstances.id IS NULL

Same goes for addressbooks and calendarobjects. This should not be a problem (apart from unnecessary disk usage and privacy concerns (GDPR) when used in SaaS environments). However if too much is deleted (#1048) this would be a severe problem.

[PatrickJMaloney]

Just set up baikal to replace macOS Server CalDAV/CardDAV. Using SQLite as this is just for me. I did just notice that deleting a calendar from the macOS Calendar app orphans all the events (as the count on the baikal admin dashboard does not go down). However, if I delete a calendar from the baikal admin interface, it appears to clean up the events.

But, based on other comments, perhaps this issue goes beyond what I'm seeing.

Any chance someone could come up with SQL to remove orphaned objects?