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

Supports "Any" in loader types #536

Merged
merged 2 commits into from
Nov 14, 2023
Merged

Supports "Any" in loader types #536

merged 2 commits into from
Nov 14, 2023

Conversation

elijahbenizzy
Copy link
Collaborator

@elijahbenizzy elijahbenizzy commented Nov 14, 2023

There are certain cases where the loader can load any datatype , E.G. pickle-type loaders. Before this didn't work. The "proper" solution would be to change custom_subclass_check, but that has the possibility of breaking some cases of materialization as we have not always been consistent here. In this case, it just uses a loader with Any if another has not been specified. While this might casue the order to be slightly counter-intuitive, it will ensure full backwrads compatibility.

[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.

Copy link
Contributor

sweep-ai bot commented Nov 14, 2023

Apply Sweep Rules to your PR?

  • Apply: All new business logic should have corresponding unit tests.
  • Apply: Refactor large functions to be more modular.
  • Apply: Add docstrings to all functions and file headers.

There are certain cases where the loader can load any datatype , E.G.
pickle-type loaders. Before this didn't work. The "proper" solution
would be to change custom_subclass_check, but that has the possibility
of breaking some cases of materialization as we have not always been
consistent here. In this case, it *just* uses a loader with `Any` if
another has not been specified. While this might casue the order to be
slightly counter-intuitive, it will ensure full backwrads compatibility.
hamilton/base.py Outdated Show resolved Hide resolved
This assumed a dataframe output, even though it was dependent on the
result builder. This fixes it.
@skrawcz skrawcz merged commit c3203ce into main Nov 14, 2023
@skrawcz skrawcz deleted the materializer-fixes branch November 14, 2023 05:34
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