Hi there,
loving GRDB and migrating from 5 to 6 where persistance callbacks have been introduced.
I would like to clean up data in another table after a record has been deleted. I would use the callback didDelete. Unfortunately I do not get the DB context handed by the callback function.
I could use willDelete - there the DB is passed to the callback. I wonder what is the reason limiting DB access for didDelete?
Thank you very much for any hint.
Hello @morstin, thank you for the feedback.
It looks like an oversight indeed. I don't see any reason for preventing didXxx callbacks from accessing the database.
If the deletion has a row should always trigger the deletion of related rows, then what you are looking for is probably not to perform cleanup from your app code, but to define a foreign key with a delete cascade in the database, so that SQLite automatically performs the cleanup for you, with zero risk of integrity loss: GRDB Documentation – Swift Package Index
For other kinds of "clean up", you don't have any much solution, but to make sure that the delete calls are always followed by the cleanup code, in your application.
I'll have a closer look at callbacks in the next major release of the lib, where I can introduce this kind of breaking change.
Hello @gwendal.roue, thank you for your quick answer.
I had to think about your delete cascade proposal. Unfortunately my wished cascade "goes the wrong direction".
As I understand cascading: if the record in the parent table is deleted, it deletes all childs to this parent record.
I want: When a child is deleted, also delete the parent, if no other child of the parent is existing. This is also the reason I need the didDelete callback.
Thank you very much for considering making db available in all callbacks in the future.
Thank you again for your reply!
Indeed this can't be achieved with a cascade. You might be interested in this previous discussion: Deleting in a many-to-many relationship · groue/GRDB.swift · Discussion #1609 · GitHub