Skip to content

Schema migration tools. #8

@amcgregor

Description

@amcgregor

From #python:

<ssbr_at_work> IDK. These days when I look at schemas, the core question I want to have answered is, "how do I keep forward and backward compatibility?"
<ssbr_at_work> File formats need to answer that question, universally, don't they? Why don't the schema formats help?
<ssbr_at_work> GothAlice: IMO you should borrow extensively from cap'n proto / protocol buffers

<ssbr_at_work> GothAlice: So you write a serialization protocol that has a lot of freedom for forward/backward compatibility reasons, and then for a specific version you write a validator that ignores things it doesn't know about.
<ssbr_at_work> GothAlice: so IMO the only thing marrow should remember from the lessons learned by protobuf/cap'n proto is not to reject unknown values
<sproingie> ssbr_at_work: i think it's that protocol compatibility is much more complicated than locking it down to a particular version number or required fields, so it punts and leaves it up to the application layer to decide unless you avail yourself of explicitly marking things required
<ssbr_at_work> sproingie: marking things as required is an antipattern in protocol buffer land, to the extent that it's forbidden in cap'n proto
<ssbr_at_work> GothAlice: protocol buffers have a few ways they deal with unknown values that might be interesting to you as alternate options (or defaults)
<ssbr_at_work> GothAlice: in particular, unknown fields are totally ignored, unknown values for known fields are read as a "default" known value

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions