[ENH} Conditional Join

[samukweku]

PR Description

Please describe the changes proposed in the pull request:

• Supports non-equi joins
• Supports combination of equi and non-equi joins
• join operator can be any of ==, !=, <=, <, >=, >, or a combination.
• Uses binary search (pandas searchsorted), avoiding a cartesian merge, making it less memory intensive
• output is similar to what obtains from SQL.
• inner, left, right joins supported. Full outer join is not supported.

This PR resolves #737 .

Please ensure that you have done the following:

1. PR in from a fork off your branch. Do not PR from <your_username>:dev, but rather from <your_username>:<feature-branch_name>.

2. If you're not on the contributors list, add yourself to AUTHORS.rst.

3. Add a line to CHANGELOG.md under the latest version header (i.e. the one that is "on deck") describing the contribution.
   • Do use some discretion here; if there are multiple PRs that are related, keep them in a single line.

Automatic checks

There will be automatic checks run on the PR. These include:

• Building a preview of the docs on Netlify
• Automatically linting the code
• Making sure the code is documented
• Making sure that all tests are passed
• Making sure that code coverage doesn't go down.

Relevant Reviewers

Please tag maintainers to review.

• @ericmjl

[codecov]

Codecov Report

Merging #861 (308817b) into dev (7189d6d) will increase coverage by 0.73%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev     #861      +/-   ##
==========================================
+ Coverage   94.92%   95.66%   +0.73%     
==========================================
  Files          19       19              
  Lines        2089     2444     +355     
==========================================
+ Hits         1983     2338     +355     
  Misses        106      106              

[ericmjl]

SMAHT!

[ericmjl]

Tremendous work, @samukweku! I mostly checked for docstrings as I trust the implementation is working (esp. based on the tests). The changes requested here should be pretty minor, and I've included a suggested change to make it easy for you if you decide to accept them.

[samukweku]

@ericmjl @loganthomas @nvamsikrishna05 made some changes; ready for another round of review. Would also appreciate a review of #857

[ericmjl]

All good from my side, @samukweku!

[ericmjl]

@nvamsikrishna05 would you like to take a stab at a review here? Let us know in dev team chat if you'd like guidance on how we do review - though I suspect you might have a lot of experience to share with us rather than the other way around 😄.

[nvamsikrishna05]

@ericmjl Thanks for confidence 🙂. It's a go ahead from my side. I do code reviews at my job too but almost all of them are either .Net based / JS based code reviews, so I may not be able to provide pythonic code review comments.

@samukweku Looks good. Approving the PR. you can go ahead and merge it.
Just a couple minor pointers you can consider(coming from a OOPS background)

• Instead of magic numbers and strings you can possibly use Enums in places where-ever applicable like in the operators(">" etc) to enforce more safety.
• Use sets instead of tuples if all you want to check is existance. Sets are constant time complexity over tuples and list. In your PR it doesn't make a difference since there are hardly 5-6 items, so no need to change.

[samukweku]

@nvamsikrishna05 thanks; could you point me to the lines of code you are referring to? the enums and the set check? thanks

[nvamsikrishna05]

@samukweku Just marked couple of instances if you want to have a look.

[ericmjl]

@samukweku same here with the conflicts - when we merge, @nvamsikrishna05 would you like to do the honors?