Refactor DownloadStub hash calculation and rename DownloadItemType.song to track #1097
Conversation
This time, the download system should not break from this change.
| track("song", true, true), | ||
| image("image", true, true), | ||
| anchor("anchor", false, false), | ||
| finampCollection("finampCollection", false, false); | ||
|
|
||
| const DownloadItemType(this.requiresItem, this.hasFiles); | ||
| const DownloadItemType(this.isarType, this.requiresItem, this.hasFiles); | ||
|
|
||
| ///!!! Used by `DownloadStub.getHash` to calculate the isarId for | ||
| ///!!! the downloads system, DO NOT EDIT for any existing entries. | ||
| ///!!! Doing so would invalidate existing downloads | ||
| ///!!! and cause them to be deleted and re-downloaded. | ||
| final String isarType; |
There was a problem hiding this comment.
so this (and the updated hash calculation) is the juicy bit, right? That looks like it would solve the issue on an API issue at least 👍🏻
And theoretically we could add a proper migration later on, that updates hashes based on the new calculation method or something, but that might be unnecessary.
Using hard-coded strings instead of enum names seems like a good idea anyway, considering that other enum options might be renamed later on as well.
There was a problem hiding this comment.
Yes & yes. The only thing missing for this PR is doing some testing, which I couldn't do last weekend, but I'll hopefully have the time to do that later this week.
Oh, and I need to rebase and fix the merge conflicts.
A migration would definitely be possible, but I'll leave that to someone more knowledgeable with isar 😅
There was a problem hiding this comment.
Okay. Let me know if you want me to test things as well.
And why do you want to rebase-merge? What's the benefit? I've only ever used the two other options...
Haven't yet verified my claim that this doesn't break anything, so draft for now. Should be rebase-merged to keep the history later on.