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

Multiple matchers in custom serializer #898

Open
tylerlaprade opened this issue Oct 11, 2024 · 3 comments
Open

Multiple matchers in custom serializer #898

tylerlaprade opened this issue Oct 11, 2024 · 3 comments
Labels

Comments

@tylerlaprade
Copy link

Hi, is it possible to use multiple matchers in a single custom serializer?
Right now I have this, but I want to add another matcher for datetime fields without disrupting my number matcher:

        return self.serializer_class.serialize(
            data,
            exclude=exclude,
            include=include,
            matcher=path_type(types=(float, Decimal), replacer=number_normalizer),
        )

I'm not seeing anything about this in the README

@noahnu
Copy link
Collaborator

noahnu commented Oct 17, 2024

The matcher is just a function that takes the data and path and returns the transformed data. path_type is a factory function. You can see the implementation here:

def path_type(

I'm open to the idea of an alternative API to provide some syntactic sugar for per type replacers. If you have a suggestion or would like to propose a PR, it'd be appreciated. Otherwise you can achieve your objective with a custom matcher function. I can provide an example at some point later this week.

@tylerlaprade
Copy link
Author

Thanks @noahnu. So you're suggesting for now I would make it match both types, then filter inside the matcher by type for the different logic? I can work with that for now.

In the long run, I'd suggest matchers which would take an array of the current matcher object. Any that contain matching types should be applied, sequentially if multiple are matched.

@tylerlaprade
Copy link
Author

Actually, thinking more on this, for my current usecase I think I'd be better off excluding entirely the audit timestamp fields, which I should be able to do with exclude. But I can see how I might need to match different types against different logic in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants