Correctly handle masking in add_row() after #8789#8907
Merged
taldcroft merged 1 commit intoastropy:masterfrom Jun 29, 2019
Merged
Correctly handle masking in add_row() after #8789#8907taldcroft merged 1 commit intoastropy:masterfrom
taldcroft merged 1 commit intoastropy:masterfrom
Conversation
Member
Author
|
Thanks @astrofrog ! I actually forgot about this... |
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
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.
I noticed that
add_row()was not updated correctly handle the Table mask behavior change in #8789. In particular it was setting the whole Table to be masked if a column became masked, except that the new_set_masked()method is not really doing that job any more.This is basically a follow-on to #8789 and only affects dev, hence no change log entry required.
The change in
data_info.pyis a little out of scope, but this is basically fixing an issue whereinsertin a mixin column would return an object withoutinfo.nameset correctly (at least forTime, it seems to be OK forQuantitywhich I did not totally understand). This was being handled byadd_row(), but I think it's better to put this into the lower level behavior. I think this issue aboutinsertis so obscure that it does not warrant a change log entry, but if anyone objects I can do that.OK, it fixes another (never-before-reported and obscure) bug: