Refactor Database Model and Schema

[amorenoz]

Right now, the way we use the dbModel and the Schema is unclean and error prone.

First, we have to hold pointers to them all around the code. Also, we use the dbModel to build Model instances but use the schema to populate their fields which can lead to errors. As an example, if you take the current main branch, build the ovsdb-server and try to use cmd/stress on it, the client will crash with:

panic: FieldByColumn: column dpdk_initialized not found in orm info

In this case, although validation passes (having partial Models is OK), the cache does not have the dbModel handy when it's filling up the fields.

Therefore, IMHO, it's clear that dbModel and schema are two sides of the same coin. The fact that server.go had to define a struct that holds both and is called DatabaseModel is a good proof of this:

libovsdb/server/server.go

Lines 31 to 34 in f2b3ce2

	type DatabaseModel struct {
	Model *model.DBModel
	Schema *ovsdb.DatabaseSchema
	}

In addition, model.Info structures are created all over the code (e.g: api) that then calls Mapper functions that create model.Infostructures all over again.

Try to improve all this by performing the following refactorings:

Rename current DbModel to ClientDBModel and introduce an internal DatabaseModel type

After the rename, a DatabaseModel type is introduced that combines both central objects that are core for the library and that supports 2-step initialization to allow the schema to be provided afterwards (on [re-]Connect()). Validation is performed on the second step (without modifying the validation logic)

mapper.Mapper to use mapper.Info

Unify the Mapper into a more compact API by having mapper.Mapper functions accept a mapper.Info reference.

Use the DatabaseModel to optimize the mapper.Infocreation

Now that we have unified all the model handling inside a single struct (DatabaseModel), use it to create mapper.Info types. Since the mapper.Info is nothing but a metadata object attached to a Model pointer, this allows for an optimization: when we validate the schema and the ClientDBModel we can create all the metadata objects and cache them. Creating a new model.Info object is now faster as the Metadata object has already been created and stored .

Reviewer notes: Although it provides little functionality change, this PR has a lot of modifications. I've tried to split the PR in commits that are easy to review

[dave-tucker]

@amorenoz need to fix lint errors 😉

[dave-tucker]

A couple of nits but overall this looks good to me. Great work @amorenoz

[coveralls]

Pull Request Test Coverage Report for Build 1380776992

• 308 of 378 (81.48%) changed or added relevant lines in 15 files are covered.
• 9 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.3%) to 73.133%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
client/api.go	12	14	85.71%
client/monitor.go	0	2	0.0%
server/database.go	5	7	71.43%
server/server.go	6	8	75.0%
model/client.go	46	50	92.0%
client/client.go	26	31	83.87%
mapper/mapper.go	31	36	86.11%
server/transact.go	34	39	87.18%
client/condition.go	18	26	69.23%
cache/cache.go	33	44	75.0%

Files with Coverage Reduction	New Missed Lines	%
server/transact.go	1	67.1%
cache/cache.go	2	70.58%
client/client.go	6	67.67%

Totals
Change from base Build 1364201130:	0.3%
Covered Lines:	4113
Relevant Lines:	5624

---

💛 - Coveralls