Adding a "Discover" object for finding candidate tables that may be joined on the main table #1153
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.
Hello, this will be a long one!
The objective of this PR is adapting part of the pipeline from this paper: https://arxiv.org/abs/2402.06282 (repo https://github.com/rcap107/retrieve-merge-predict).
Main points:
transform
is a ranking of candidate joins that includes the query column in the main table, the path to the candidate table, the key in the candidate table and the containmentSome of the problems/things that should be considered for later:
MultiAggJoiner
could be used at the end to combine all the candidates into a big table.Notes on the current implementation:
_discover.py
for now.read_parquet
andread_csv
dispatched functions, but I am having trouble because the only argument that they need isinput_path
, and the dispatcher can't use that to decide which library to use. For the time being, I am passing X just to give that information.Discover
object are not in the class itself, should I move them in? It's probably the better option.The current code version is barebones, but it runs. Mostly, I am having trouble with integrating the code properly.