Fix expression column aggregate calculation with group_by after remove()#2311
Merged
Fix expression column aggregate calculation with group_by after remove()#2311
group_by after remove()#2311Conversation
203c92b to
799691c
Compare
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.
Fixes a bug which causes expression columns to show
nullor0results when aremove()had taken place before.When a
Viewwithexpressionsis created from aTablethat has hadremove()applied to it, some aggregates (likesum) are calculated incorrectly, as in the example below. Interestingly, this issue only occurs when theremove()occurs before theview(). If allremove()calls occur after the view is created, a slightly different code path correctly calculates the expressions.Ultimately this issue was caused by a few under-tested code paths, in which he wrong mapping was chosen deep in a giant block of data processing code., given a choice between the "original" and
remove()-corrected indices when matching primary keys to column's row index. The repro (below), simple as it is, was instrumental in identifying and fixing it.Fixes #1710 (???)