Basic Notation
--------------
+OVSDB uses JSON, as defined by RFC 4627, for its schema format and its
+wire protocol format. The JSON implementation in Open vSwitch has the
+following limitations:
+
+ - Null bytes (\u0000) are not allowed in strings.
+
+ - Only UTF-8 encoding is supported. (RFC 4627 also mentions
+ UTF-16BE, UTF-16LE, and UTF-32.)
+
+ - RFC 4627 says that names within a JSON object should be unique.
+ The Open vSwitch JSON parser discards all but the last value
+ for a name that is specified more than once.
+
The descriptions below use the following shorthand notations for JSON
values. Additional notation is presented later.
A JSON object with the following members:
"name": <id> required
- "comment": <string> optional
"tables": {<id>: <table-schema>, ...} required
The "name" identifies the database as a whole. It must be
provided to most JSON-RPC requests to identify the database being
- operated on. The "comment" optionally provides more information
- about the database. The value of "tables" is a JSON object whose
- names are table names and whose values are <table-schema>s.
+ operated on. The value of "tables" is a JSON object whose names
+ are table names and whose values are <table-schema>s.
<table-schema>
A JSON object with the following members:
- "comment": <string> optional
"columns": {<id>: <column-schema>, ...} required
+ "maxRows": <integer> optional
- The "comment" optionally provides information about this table for
- a human reader. The value of "columns" is a JSON object whose
- names are column names and whose values are <column-schema>s.
+ The value of "columns" is a JSON object whose names are column
+ names and whose values are <column-schema>s.
Every table has the following columns whose definitions are not
included in the schema:
the database process is stopped and then started again, each
"_version" also changes to a new random value.
+ If "maxRows" is specified, as a positive integer, it limits the
+ maximum number of rows that may be present in the table. This is
+ a "deferred" constraint, enforced only at transaction commit time
+ (see the "transact" request below). If "maxRows" is not
+ specified, the size of the table is limited only by the resources
+ available to the database server.
+
<column-schema>
A JSON object with the following members:
- "comment": <string> optional
"type": <type> required
"ephemeral": <boolean> optional
- The "comment" optionally provides information about this column
- for a human reader. The "type" specifies the type of data stored
- in this column. If "ephemeral" is specified as true, then this
- column's values are not guaranteed to be durable; they may be lost
- when the database restarts.
+ The "type" specifies the type of data stored in this column. If
+ "ephemeral" is specified as true, then this column's values are
+ not guaranteed to be durable; they may be lost when the database
+ restarts.
<type>
"minLength": <integer> optional, strings only
"maxLength": <integer> optional, strings only
"refTable": <id> optional, uuids only
+ "refType": "strong" or "weak" optional, only with "refTable"
An <atomic-type> by itself is equivalent to a JSON object with a
single member "type" whose value is the <atomic-type>.
bytes or UTF-16 code units).
If "type" is "uuid", then "refTable", if present, must be the name
- of a table within this database. If "refTable" is set, the
- allowed UUIDs are limited to UUIDs for rows in the named table.
+ of a table within this database. If "refTable" is specified, then
+ "refType" may also be specified. If "refTable" is set, the effect
+ depends on "refType":
+
+ - If "refType" is "strong" or if "refType" is omitted, the
+ allowed UUIDs are limited to UUIDs for rows in the named
+ table.
+
+ - If "refType" is "weak", then any UUIDs are allowed, but
+ UUIDs that do not correspond to rows in the named table will
+ be automatically deleted.
"refTable" constraints are "deferred" constraints: they are
enforced only at transaction commit time (see the "transact"
* The JSON-RPC specification for HTTP transport is incomplete.
+We are using TCP port 6632 for the database JSON-RPC connection.
+
The database wire protocol consists of the following JSON-RPC methods:
list_dbs
When the commit was attempted, a column's value referenced the
UUID for a row that did not exist in the table named by the
- column's <base-type> key or value "refTable". (This can be
- caused by inserting a row that references a nonexistent row,
- by deleting a row that is still referenced by another row, by
- specifying the UUID for a row in the wrong table, and other
- ways.)
+ column's <base-type> key or value "refTable" that has a
+ "refType" of "strong". (This can be caused by inserting a row
+ that references a nonexistent row, by deleting a row that is
+ still referenced by another row, by specifying the UUID for a
+ row in the wrong table, and other ways.)
+
+ "error": "constraint violation"
+
+ A column with a <base-type> key or value "refTable" whose
+ "refType" is "weak" became empty due to deletion(s) caused
+ because the rows that it referenced were deleted (or never
+ existed, if the column's row was inserted within the
+ transaction), and this column is not allowed to be empty
+ because its <type> has a "min" of 1.
+
+ "error": "constraint violation"
+
+ The number of rows in a table exceeds the maximum number
+ permitted by the table's "maxRows" value (see <table-schema>).
If "params" contains one or more "wait" operations, then the
transaction may take an arbitrary amount of time to complete. The
"params": [<db-name>, <json-value>, <monitor-requests>] required
"id": <nonnull-json-value> required
-<monitor-requests> is an object that maps from a table name to a
-<monitor-request>.
+<monitor-requests> is an object that maps from a table name to an
+array of <monitor-request> objects. For backward compatibility, a
+single <monitor-request> may be used instead of an array; it is
+treated as a single-element array.
Each <monitor-request> is an object with the following members:
"id": same "id" as request
This JSON-RPC request enables a client to replicate tables or subsets
-of tables within database <db-name>. Each <monitor-request> specifies
-a table to be replicated. The JSON-RPC response to the "monitor"
-includes the initial contents of each table. Afterward, when changes
-to those tables are committed, the changes are automatically sent to
-the client using the "update" monitor notification. This monitoring
-persists until the JSON-RPC session terminates or until the client
-sends a "monitor_cancel" JSON-RPC request.
+of tables within database <db-name>. Each element of
+<monitor-requests> specifies a table to be replicated. The JSON-RPC
+response to the "monitor" includes the initial contents of each table,
+unless disabled (see below). Afterward, when changes to those tables
+are committed, the changes are automatically sent to the client using
+the "update" monitor notification. This monitoring persists until the
+JSON-RPC session terminates or until the client sends a
+"monitor_cancel" JSON-RPC request.
-Each <monitor-request> describes how to monitor a table:
+Each <monitor-request> describes how to monitor columns in a table:
The circumstances in which an "update" notification is sent for a
row within the table are determined by <monitor-select>:
sent whenever when a row in the table is modified.
The "columns" member specifies the columns whose values are
- monitored. If "columns" is omitted, all columns in the table,
- except for "_uuid", are monitored.
+ monitored. It must not contain duplicates. If "columns" is
+ omitted, all columns in the table, except for "_uuid", are
+ monitored.
+
+If there is more than one <monitor-request> in an array of them, then
+each <monitor-request> in the array should specify both "columns" and
+"select", and the "columns" must be non-overlapping sets.
The "result" in the JSON-RPC response to the "monitor" request is a
<table-updates> object (see below) that contains the contents of the