Two Way Serialization
See original GitHub issueTrying to cope with this without writing two schemes for the same stuff.
Let’s say I’m taking in one API and it gives me something like this:
{
"CamelCased": "Stuff",
"somethingElse": "More stuff",
"OhLookAList": [1,2,3,4]
}
And I’m repackaging it, doing some fun stuff internally, and then dumping it out the other side into my own API. Don’t ask why I can’t keep the same names.
{
"camel_cased": "That's a lie now.",
"something_else": "More stuff",
"oh_look_a_list": [1,2,3,4]
}
Normally I’d just use dump_to/load_from and be done with it all…however, I need to reverse the flow and send information from my API back to the external API. So someone will post:
{
"camel_cased": "That's a lie now.",
"something_else": "More stuff",
"oh_look_a_list": [1,2,3,4]
}
And the external API will get…
{
"CamelCased": "Stuff",
"somethingElse": "More stuff",
"OhLookAList": [1,2,3,4]
}
In the example text for marshmallow-enum I used a (nasty, in my opinion) pre_load/pre_dump workaround that looked at the schema context to see if the incoming data was the internal source or external source, and then switched a value on the field. However, I’m hesitant to do that for an entire schema.
The best way I can think to handle this with Marshmallow is to just some sort of schema factory that’d create external/internal schemas on demand, potentially a less crappy version of this:
def make_two_way_schema(context):
class SomeSchema(Schema):
id = fields.Str(load_from=context['id']['read'], dump_to=context['id']['write'])
return SomeSchema(...)
However, I’m unplussed about this idea or the prospect of managing two sets of schemas. I could see manufacturing the schemas before hand – using the above mechanism – and then at dump/load time choose the correct one. Maybe something like…
def make_two_way_schema(mapping):
internal_to_external = ...
external_to_internal = ...
def schema_choose(...): # all the same args as Schema.__init__
return internal_to_external if context['source'] == 'internal' else external_to_internal
return schema_choose
This strikes me as the lesser of two evils but not by much… Any ideas?
Issue Analytics
- State:
- Created 8 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
They way I’ve handled this is not always dump.
load_from
is an additional field to the one specified to the left of the equal sign.SomeSchema
Comes in as camelCase, and we want camelCase out
Comes in as camelCase, and we want snake_case out
Comes in as snake_case, and we want camelCase out
Comes in as snake_case, and we want snake_case out
Let me know if that helps!
Hey, for the history, @sloria added a code example that solves it recently. Also, #1295