iTunes: Re-enable test and add composer, playCount, lastPlayedAt and dateAdded to model
#11948
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fwcd
changed the title
composer, playCount, lastPlayedAt and dateAdded to model
|
Interesting, GCC seems to be rather strict with omitted fields in C++20's designated initializers, which I thought were explicitly intended to allow default initialization of their omitted members... |
Let's hope that this makes GCC happy
|
Thank you |
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now that #11666 has been merged, this re-enables the iTunes test. Additionally it adds a few new fields to
ITunesTrack(along with the corresponding XML and macOS import implementations) that map directly to fields that Mixxx uses for its library tracks:QString composerint playCountQDateTime lastPlayedAtQDateTime dateAddedThe test is also updated to expect these new fields.
Note, however, that this is only the first piece of the puzzle, this PR won't make the fields user-visible yet. For that, the database schema has to be updated (albeit in a backwards-compatible-way). Since that's a more invasive change, my plan was to do that in a separate PR.
I'm targeting 2.4 since these changes should be pretty safe to merge and only affect testing. Should the follow-up PR (changing the schema to add the respective new columns to the db) also target 2.4 or is that too large of a change? Feel free to leave some notes.