Add upgrade management logic to omit deletion of extras #10836
Conversation
Also covers the case when a better movie file is placed manually in the folder, which would be detected during a disk scan but doesn't set any old files in MovieFileImportedEvent.
| var extrasToMigrate = _repository.GetFilesByMovie(message.ImportedMovie.MovieId) | ||
| .FindAll(extra => extra.MovieFileId != message.ImportedMovie.Id) | ||
| .Select(extra => | ||
| { | ||
| extra.MovieFileId = message.ImportedMovie.Id; | ||
| return extra; | ||
| }) | ||
| .ToList(); |
There was a problem hiding this comment.
Looking at this, I don't think we can merge this if we ever want multi-part support to happen. Works fine with a single file, but it won't with multiples.
There was a problem hiding this comment.
Ignoring upgrades for a moment, if I understand what you're saying, it would mean that extras would have to be decoupled from movie file IDs anyway, right? They will only be linked to a movie ID regardless of how many files comprise it.
If that's the case, then I think the new logic that I implemented in this PR to handle MovieFileImportedEvent could be completely removed when multi-part support is implemented. So multi-part support would even simplify the upgrade logic.
I might be missing something since I'm not familiar with the whole code base, so correct me if I'm wrong.
Database Migration
NO
Description
This is based on the discussion in #4650 and related issues, although the changes in this PR only target upgrades. The user can decide which type of extra files shouldn't be deleted when a movie is upgraded. Since the file ID changes during an upgrade, it seems that the database needs to be updated for any extras that were not deleted, which is why
ExtraFileService<TExtraFile>now implementsIHandleAsync<MovieFileImportedEvent>.I tried a few scenarios locally and it seems to work as desired. Let me know what you think.
Screenshot (if UI related)
Todos