Always use specific null values for fixed fields #2605
Merged
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
This came out of an attempt to address the mysterious testing problems from PR #2563 and turned into a big old debacle. As it turns out, the problem came from calling Item.from_path and getting None for fields that weren't filled out by the MediaFile data. Everywhere else, we fill out these fixed attributes with the special null value for the field's type, so it's actually pretty confusing that these could mysteriously become None. I think it will be saner all around if we enforce this universally. There were two possible fixes: one in __getitem__ to check for missing values and one that set all the missing values in the constructor. I opted for the former because it has a smaller footprint, but the latter might have slightly better performance (depending on the ratio of constructions to lookups).
These were written to incidentally depend on Nones; the behavior they're actually testing doesn't really have anything to say about None-ness.
We really want `Album.artpath` to be None sometimes, and this was relying on some accidental dbcore behavior before. Now, we explicitly mark the field as nullable: it may be a path, or it may be None to indicate that there is no art.
Fixes a `modify` test, of all things.
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.
This came out of an attempt to address the mysterious testing problems from #2563 and turned into a big old debacle. As it turns out, the problem came from calling Item.from_path and getting None for fields that weren't filled out by the MediaFile data. Everywhere else, we fill out these fixed attributes with the special null value for the field's type, so it's actually pretty confusing that these could mysteriously become None. I think it will be saner all around if we enforce this universally.
There were two possible fixes: one in
__getitem__to check for missing values and one that set all the missing values in the constructor. I opted for the former because it has a smaller footprint, but the latter might have slightly better performance (depending on the ratio of constructions to lookups).There were a few tests that implicitly depended on the old behavior, which I've fixed. I've also fixed a couple of fields that were relying implicitly on the old sometimes-None, sometimes-not behavior to explicitly allow the fields to be None. (Namely,
artpathandinitial_key.)