All of these changes avoid using the same name for two local variables
within a same function. None of them are actual bugs as far as I can tell,
but any of them could be confusing to the casual reader.
The one in lib/ovsdb-idl.c is particularly brilliant: inner and outer
loops both using (different) variables named 'i'.
Found with GCC -Wshadow.
The declaration of "error" that this commit removes shadowed an outer local
declaration of "error", which caused errors detected by this code not to be
propagated up to the outer level.
Found with GCC -Wshadow.
This also adds protocol compatibility to the database itself and to
ovsdb-client. It doesn't actually add multiple database support to
ovsdb-server, since we don't really need that yet.
The "declare" operation is specified to return a <uuid>, e.g.:
["uuid", "7b703002-f7b6-45c6-bfd6-7619b21a1a5f"]
It was actually just returning the second part, e.g.
"7b703002-f7b6-45c6-bfd6-7619b21a1a5f"
This commit makes the result match the specification.
Some of these are serious leaks, in that they could leak some amount of
memory for every transaction processed by the database server.
Found with valgrind.
The idea here is that transaction comments get copied to the ovsdb-server's
transaction log, which can then make it clear later why a particular change
was made to the database, to ease debugging.
This allows a transaction like this:
[{"op": "insert",
"table": "mytable",
"row": {"i": 0, "k": ["named-uuid", "self"]},
"uuid-name": "self"}]
It was already possible to do this by following up on the "insert" with an
"update", but since this was easy to implement I did it.
An upcoming commit will add support for replicating tables across JSON-RPC
connection. As a prerequisite ovsdb itself must support basic replication.
This commit adds that support and then reimplements the ovsdb file storage
in terms of that replication.
