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

Add transform proposal #113

Merged
merged 5 commits into from
Mar 15, 2024
Merged

Add transform proposal #113

merged 5 commits into from
Mar 15, 2024

Conversation

nicholasjng
Copy link
Collaborator

Based on the changes contained in #110 (although mostly if not entirely orthogonal).

The proposed Transform class is a thin, possibly stateful class mapping
records to other records.

It is generally assumed to be invertible, which is expressed by the
addition of an iapply() method (name pending), which can be used to
(approximately) revert records to their old form IF the given transform
supports it.

The added script showcases both proposals, with a barebones example of
why it is useful: To serialize a given model into a set of digestible,
unique identifiers, and doing the reverse in the inverse method.

This way, even custom model classes can be written to JSON, where they
are (very simply) saved via their chosen transform parametrization.

@nicholasjng nicholasjng self-assigned this Mar 13, 2024
@nicholasjng nicholasjng marked this pull request as ready for review March 14, 2024 14:38
@nicholasjng nicholasjng requested a review from maxmynter March 14, 2024 14:38
@nicholasjng
Copy link
Collaborator Author

Question for reviewer(s):

  • Should the transform methods become abstract?
  • How would you design APIs verifying the transform capabilities hardcoded as bool attributes?

The proposed `Transform` class is a thin, possibly stateful class mapping
records to other records.

It is generally assumed to be invertible, which is expressed by the
addition of an `iapply()` method (name pending), which can be used to
(approximately) revert records to their old form IF the given transform
supports it.

The added script showcases both proposals, with a barebones example of
why it is useful: To serialize a given model into a set of digestible,
unique identifiers, and doing the reverse in the inverse method.

This way, even custom model classes can be written to JSON, where they
are (very simply) saved via their chosen transform parametrization.
Contains the basic definitions for 1->1, N->1 and N->N record transforms.

Right now, this comes without guarantees or enforcement of attributes
(invertibility/length preservation), but this can be added in the future.

Users have to mark transform capabilities on their own.
Thanks to the new base class, this is a no-brainer.
Covers the basic ideas, includes a usage example, and gives tips on what
to consider when designing transforms.
Copy link
Collaborator

@maxmynter maxmynter left a comment

Choose a reason for hiding this comment

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

We could make the apply method abstract and then infer the invertible property based on whether iapply is overridden.

examples/transforms/transforms.py Show resolved Hide resolved
examples/transforms/transforms.py Outdated Show resolved Hide resolved
Trim a leftover comment, adjusting the snippet line numbers in the process.
@nicholasjng nicholasjng merged commit cdf4884 into main Mar 15, 2024
5 checks passed
@nicholasjng nicholasjng mentioned this pull request Mar 15, 2024
2 tasks
@nicholasjng nicholasjng deleted the transforms branch March 18, 2024 14:45
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