Default to None for values which don't exist in lookup_data #37
Conversation
This file contains hidden or 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
I have very split opinions about this over throwing errors. The problem with throwing errors are that they break the loop, so you would have to override the entire prepare method to properly handle them being thrown. I'm super open to suggestions.
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.
Basically an alternate solution to #30
Erroring out of the loop of fields for lookup_data makes it hard to properly catch errors without overriding the entire prepare method (which is fine, but forces people to look at the source code (which is also fine haha)). The problem with this solution is that it does not fail so people will not know if they misspelled their fields, they will need to realize this based on the field they are looking for being
nullwhen it really shouldn't be.My alternate solution (which I have yet to implement and is still brewing in my mind) is to be able to hook into the for loop in the prepare method so that errors to it could be handled on a per-field basis.