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.

Sign up for GitHub

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

Jump to bottom

RFC: Enhance compatibility with different schema versions #244

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

RFC: Enhance compatibility with different schema versions #244

wants to merge 10 commits into from

Commits on Oct 13, 2021

  1. client_test: fix monitor cookie json 

    MonitorCookies are marshalled as a json object, not an array. Fix it so
that benchmark test works

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    fa84414 View commit details
    Browse the repository at this point in the history

  2. example: fix ovsdb-server schema file 

    Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    8ef7753 View commit details
    Browse the repository at this point in the history

  3. rename DBModel to DatabaseModelRequest 

    Clearly DBModel does not hold the full database model. Instead, only
the combination of model.DBModel, mapper.Mapper and ovsdb.Schema is a
useful database model.

The fact that server.go had to defined a struct called DatabaseModel
with model.DBModel and ovsdb.Schema and dymanically create Mapper
objects from them is a proof of this.

In order to prepare for a DBModel refactoring, rename it to
DatabaseModelRequest as it's what the client requests the DatabaseModel
to look like.

This patch does not contain functional changes

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    19c8539 View commit details
    Browse the repository at this point in the history

  4. model: Introduce DatabaseModel 

    Replace the one that server.go had to define. For now, it's just a
drop-in replacement of the previous type

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    d1894d4 View commit details
    Browse the repository at this point in the history

  5. database: Add 2-step initialization 

    It is common to first create a DatabaseModel only based on the
DatabaseModelRequest, and then add / remove the schema to it when, e.g:
when the client (re) connects.

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    d5556fa View commit details
    Browse the repository at this point in the history

  6. client: Use DatabaseModel in client an cache 

    For the cache, it's simply replacing three fields with one
For the client, use the 2-step DatabaseModel initialization

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    81f034b View commit details
    Browse the repository at this point in the history

  7. model: move methods from Request to DatabaseModel 

    Now that client, cache and server uses the DatabaseModel as central
point of model creation and introspection, we can hide the
DatabaseModelRequest and move its pulbic functions to the DatabaseModel

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    cf54b19 View commit details
    Browse the repository at this point in the history

  8. mapper: make Mapper use mapper.Info as input 

    All around the codebase we're creating mapper.Info structures and then
calling Mapper functions that create Info structures again.

Given that mapper.Info already defines all the metadata that Mapper
needs to do the native-to-ovs transations, it makes sense to use Info
structures as input to all functions.

That simplifies the code inside the mapper module. Also, I'd expect some
performance improvement since we were creating multiple Info structs
unnecessarily in the host path.

It's true that, for now, it makes it sligthly more cumbersone to call
mapper functions, since the Info struct has to be created first and it
now requires an additional argument (the table name). However, this
can be improved later on by having the database model build the
Info structs for us.

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    3ff43c5 View commit details
    Browse the repository at this point in the history

  9. model: Use DatabaseModel to create mapper.Info 

    The core mapper API uses mapper.Info sctructs which can be created just
by inspecting a TableSchema.

However, having the DatabaseModel now centralizing accesses to the
mapper API and containing both the Model types and the Schema, we can
pre-create the mapper.Info.Metadata sctructs and cache them so we create
Info sctructs more efficiently

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    f4daab4 View commit details
    Browse the repository at this point in the history

  10. mapper: Add compatility mode 

    Allow the user to set a Compatibility flag on the DatabaseModelRequest.

When that flag is set, the verification phase will not fail if a column
is missing on the schema or has a different type. Instead it will just
skip the column.

Same goes for missing tables, they will just be skipped.

Signed-off-by: Adrian Moreno <[email protected]>
    @amorenoz
    amorenoz committed Oct 13, 2021
    Configuration menu
    Copy the full SHA
    94fd061 View commit details
    Browse the repository at this point in the history