MBS-6058: Rewrite subscription system to have proper foreign keys
ocharles
Branch: ocharles/musicbrainz-server:mbs-6058
ocharles/musicbrainz-server:mbs-6058
Branch: metabrainz/musicbrainz-server:master
metabrainz/musicbrainz-server:master
Merged
#76 · Created  · Last updated
Description
This pull request comes out of trying to solve MBS-6058, and has sadly turned into a little bit more work than originally envisioned. First, a synopsis of the problem.
HumHumXx observes that his subscriptions page indicates that he is subscribed to 7 artists, yet viewing his artist subscriptions shows the contradictory statement "no subscriptions". According to the database, HumHumXx does indeed have 7 subscriptions - subscriptions to artists who no longer exist! The editor_subscribe_artist.artist column points no where, yet deleted_by_edit and merged_by_edit are both 0, indicating that the subscription should still be valid.
Naturally, having this impossible data represented in our database was not something I was happy about, so I've come up with a slightly alternative design which I think captures what we want more elegantly.
Schema changes
Active subscriptions
Active subscriptions have a true foreign key constraint against the entity that the subscription points to. These are captured by the editor_subscribe_artist/_label tables, as before. The last_edit_sent attribute now also has a foreign key constraint. We don't delete edits, and I think we didn't have this because this data used to be in a different database.
Deleted subscriptions
A subscription is deleted if it was once active, but the entity that it referred to has been deleted, but a subscription digest has not been sent to that editor. A deleted subscription consists of the editor who held the subscription, along with the MBID that the subscription was for. This is a foreign key into the new artist_/label_deleted tables, which loosely captures the name and disambiguation comment for the entity. This could be ommited, but it seemed nice to have.
Thus, a deleted subscription must refer to an entity that is deleted.
Code changes
There was a fair bit of cruft in the subscription system, so I've factored out duplication where best I could. The main changes are mostly to do the deletion logging and deal with the new subscription tables. I got rid of the deleted_by_edit and merged_by_edit in favour of a single edit reference, as we can make use of the status information to determine why an entity was deleted.
This pull request comes out of trying to solve MBS-6058, and has sadly turned into a little bit more work than originally envisioned. First, a synopsis of the problem.
HumHumXx observes that his subscriptions page indicates that he is subscribed to 7 artists, yet viewing his artist subscriptions shows the contradictory statement "no subscriptions". According to the database, HumHumXx does indeed have 7 subscriptions - subscriptions to artists who no longer exist! The
editor_subscribe_artist.artistcolumn points no where, yetdeleted_by_editandmerged_by_editare both 0, indicating that the subscription should still be valid.Naturally, having this impossible data represented in our database was not something I was happy about, so I've come up with a slightly alternative design which I think captures what we want more elegantly.
Schema changes
Active subscriptions
Active subscriptions have a true foreign key constraint against the entity that the subscription points to. These are captured by the
editor_subscribe_artist/_labeltables, as before. Thelast_edit_sentattribute now also has a foreign key constraint. We don't delete edits, and I think we didn't have this because this data used to be in a different database.Deleted subscriptions
A subscription is deleted if it was once active, but the entity that it referred to has been deleted, but a subscription digest has not been sent to that editor. A deleted subscription consists of the editor who held the subscription, along with the MBID that the subscription was for. This is a foreign key into the new
artist_/label_deletedtables, which loosely captures the name and disambiguation comment for the entity. This could be ommited, but it seemed nice to have.Thus, a deleted subscription must refer to an entity that is deleted.
Code changes
There was a fair bit of cruft in the subscription system, so I've factored out duplication where best I could. The main changes are mostly to do the deletion logging and deal with the new subscription tables. I got rid of the
deleted_by_editandmerged_by_editin favour of a singleeditreference, as we can make use of thestatusinformation to determine why an entity was deleted.