Skip to content

Conversation

@MarkusBonsch
Copy link
Contributor

Closes #2881.
Unfortunately, my PR #2389, that introduced partial key retainment when assigning to columns, introduced a regression in bmerge.R.
bmerge.R assumed implicitely that any set() operation removes a key completely if it assigns to a key column. In contrast, the mentioned PR made it possible that a reduced key still exists when assigning to a key column.

I have done the following:

  • adapted bmerge.R so that it checks internally if the key on i is correct, instead of using the io argument. This was also mentioned as a TODO in bmerge.R sourcecode.
  • It involved a changed bmerge interface (with removed io argument), so I changed all calls to bmerge.R.
  • Additionally, the logic that sets the sorted attribute at the end of data.table.R had to be modified.

No existing tests were modified and a new test added.

This regression should occur very rarely, but if it does, it is very bad. Therefore, it might make sense to issue a quick bugfix release to CRAN rather soon?

@MarkusBonsch MarkusBonsch requested a review from mattdowle June 7, 2018 21:03
@jangorecki jangorecki added this to the 1.11.6 milestone Jun 14, 2018
Copy link
Member

@jangorecki jangorecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

io = if (missing(on)) haskey(i) else identical(unname(on), head(key(i), length(on)))
i = .shallow(i, retain.key = io)
ans = bmerge(i, x, leftcols, rightcols, io, xo, roll, rollends, nomatch, mult, ops, nqgrp, nqmaxgrp, verbose=verbose)
i = .shallow(i, retain.key = TRUE)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change of dynamic value to TRUE does not impose any more changes to bmerge and Cbmerge?

Copy link
Contributor Author

@MarkusBonsch MarkusBonsch Jun 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly believe so. Cbmerge just accepts a bool for the io argument telling if i is ordered. If not, it calls forderv. bmerge.R used to accept any existing key on i as valid for the current join without crosscheck. Now, it carefully tests if the key on i is appropriate for the problem at hand. Therefore, the now always retained key on i should make no difference IMHO.

@mattdowle mattdowle merged commit cf9d1b1 into master Aug 17, 2018
@mattdowle mattdowle deleted the subsetBugFix branch August 17, 2018 01:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] %in% statement fails if the category contains both lowercase and uppercase letters

3 participants