Skip to content
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

Data adapters #128

Merged
merged 14 commits into from
Apr 10, 2023
Merged

Data adapters #128

merged 14 commits into from
Apr 10, 2023

Conversation

elijahbenizzy
Copy link
Collaborator

[Short description explaining the high-level reason for the pull request]

Changes

How I tested this

Notes

Checklist

  • PR has an informative and human-readable title (this will be pulled into the release notes)
  • Changes are limited to a single goal (no scope creep)
  • Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
  • Any change in functionality is tested
  • New functions are documented (with a description, list of inputs, and expected output)
  • Placeholder code is flagged / future TODOs are captured in comments
  • Project documentation has been updated if adding/changing functionality.

@elijahbenizzy elijahbenizzy force-pushed the data-adapters branch 10 times, most recently from d98ec4d to 75fa69f Compare April 2, 2023 22:18
@elijahbenizzy elijahbenizzy changed the title Data adapters WIP Data adapter Apr 3, 2023
@elijahbenizzy elijahbenizzy requested a review from skrawcz April 3, 2023 00:19
See #46 for some initial
context.

Basic design is:
1. A decorator that loads data and injects into a function
2. A set of Data Loaders that can be constructed from kwargs (they're
   all dataclasses)
3. A LoadFromDecorator that takes in a variety of data loader classes
   that are possible to choose from
4. A registry that specifies a mapping of key -> data loader classes,
   allowing us to polymorphically select them

More todos, up next
1. Add tests for the default loaders
2. Add safeguards to ensure any loader is a dataclass
3. Add documentation

We also add a register_adapter function in the registry. Note that this
just moves the adapters we currently have around, and does not add new
ones.
Also moves some files to more convenient, central locations
We expect to add more optional arguments over time, but these should get
people started.
This makes data loaders specify the types they apply to, rather
than filling out the applies_to function. This way, we can easily
document which data loaders are used for which types, to make it easier
to clarify
Still don't have SQL support yet, but that's coming soon.
@elijahbenizzy elijahbenizzy changed the title Data adapter Data adapters Apr 4, 2023
@elijahbenizzy elijahbenizzy force-pushed the data-adapters branch 2 times, most recently from dffb1f3 to 097ea28 Compare April 4, 2023 02:04
This decorates the output of a function -- creating a node to append to
the end that saves it. This has similar functionality to data loaders,
and has been grouped togther under the data loading umbrella.
@elijahbenizzy elijahbenizzy marked this pull request as ready for review April 4, 2023 18:34
Copy link
Collaborator

@skrawcz skrawcz left a comment

Choose a reason for hiding this comment

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

Just some doc stuff I think, and some minor naming. Looks good otherwise.

docs/reference/api-reference/decorators.rst Show resolved Hide resolved
hamilton/function_modifiers/adapters.py Show resolved Hide resolved
hamilton/function_modifiers/adapters.py Show resolved Hide resolved
hamilton/function_modifiers/adapters.py Outdated Show resolved Hide resolved
hamilton/function_modifiers/adapters.py Outdated Show resolved Hide resolved
hamilton/io/utils.py Outdated Show resolved Hide resolved
hamilton/io/utils.py Outdated Show resolved Hide resolved
hamilton/io/utils.py Outdated Show resolved Hide resolved
This allows us to render them specially in a viz or do a query for data
sources.
For the save_to decorator. Since I think output is more consistent
with our language. We really have not been consistent in the driver/code
base at all. Choosing `output` because the `.execute()` function requests
final_vars and is documented as the `outputs` one wants. Thus I think
reading `output_name_` will help people identify that this is what they
would use if they wanted to get the results out.
@elijahbenizzy elijahbenizzy requested a review from skrawcz April 10, 2023 18:56
@elijahbenizzy elijahbenizzy merged commit 5bfdb33 into main Apr 10, 2023
@elijahbenizzy elijahbenizzy deleted the data-adapters branch April 10, 2023 19:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants