Skip to content

BUG: preserve left frame order in left merge #8948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 1, 2014
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions doc/source/whatsnew/v0.15.2.txt
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,7 @@ Bug Fixes
- ``slice`` string method now takes step into account (:issue:`8754`)
- Bug in ``BlockManager`` where setting values with different type would break block integrity (:issue:`8850`)
- Bug in ``DatetimeIndex`` when using ``time`` object as key (:issue:`8667`)
- Bug in ``merge`` where ``how='left'`` and ``sort=False`` would not preserve left frame order (:issue:`7331`)
- Fix negative step support for label-based slices (:issue:`8753`)

Old behavior:
Expand Down
4 changes: 3 additions & 1 deletion pandas/tools/merge.py
Original file line number Diff line number Diff line change
Expand Up @@ -479,8 +479,10 @@ def _get_join_indexers(left_keys, right_keys, sort=False, how='inner'):
left_group_key, right_group_key, max_groups = \
_factorize_keys(left_group_key, right_group_key, sort=sort)

# preserve left frame order if how == 'left' and sort == False
Copy link
Contributor

Choose a reason for hiding this comment

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

is this the only case where it needs/should be preserved? (e.g. what about other how's)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

in pandas/src/join.pyx only left_outer_join accepts this extra argument sort, which was added in this commit to preserve left frame order.

I think it makes sense, because except for the case of left join preserving order is not well defined or I do not see an immediate use for it.

kwargs = {'sort':sort} if how == 'left' else {}
join_func = _join_functions[how]
return join_func(left_group_key, right_group_key, max_groups)
return join_func(left_group_key, right_group_key, max_groups, **kwargs)


class _OrderedMerge(_MergeOperation):
Expand Down
12 changes: 12 additions & 0 deletions pandas/tools/tests/test_merge.py
Original file line number Diff line number Diff line change
Expand Up @@ -1022,6 +1022,13 @@ def test_left_join_index_multi_match_multiindex(self):

tm.assert_frame_equal(result, expected)

# GH7331 - maintain left frame order in left merge
right.reset_index(inplace=True)
right.columns = left.columns[:3].tolist() + right.columns[-1:].tolist()
result = merge(left, right, how='left', on=left.columns[:-1].tolist())
expected.index = np.arange(len(expected))
tm.assert_frame_equal(result, expected)

def test_left_join_index_multi_match(self):
left = DataFrame([
['c', 0],
Expand Down Expand Up @@ -1059,6 +1066,11 @@ def test_left_join_index_multi_match(self):

tm.assert_frame_equal(result, expected)

# GH7331 - maintain left frame order in left merge
result = merge(left, right.reset_index(), how='left', on='tag')
expected.index = np.arange(len(expected))
tm.assert_frame_equal(result, expected)

def test_join_multi_dtypes(self):

# test with multi dtypes in the join index
Expand Down