"columns": {<id>: <column-schema>, ...} required
"maxRows": <integer> optional
"isRoot": <boolean> optional
+ "indexes": [<column-set>*] optional
The value of "columns" is a JSON object whose names are column
names and whose values are <column-schema>s.
enforced after unreferenced rows are deleted from tables with a
false "isRoot".
+ If "indexes" is specified, it must be an array of zero or more
+ <column-set>s. A <column-set> is an array of one or more strings,
+ each of which names a column. Each <column-set> is a set of
+ columns whose values, taken together within any given row, must be
+ unique within the table. This is a "deferred" constraint,
+ enforced only at transaction commit time, after unreferenced rows
+ are deleted and dangling weak references are removed. Ephemeral
+ columns may not be part of indexes.
+
<column-schema>
A JSON object with the following members:
"ephemeral": <boolean> optional
"mutable": <boolean> optional
- The "type" specifies the type of data stored in this column. If
- "ephemeral" is specified as true, then this column's values are
+ 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. If "mutable" is specified as false, then this column's
- values may not be modified after they are initially set with the
- "insert" operation.
+ restarts. A column whose type (either key or value) is a strong
+ reference to a table that is not part of the root set is always
+ durable, regardless of this value. (Otherwise, restarting the
+ database could lose entire rows.)
+
+ If "mutable" is specified as false, then this column's values may
+ not be modified after they are initially set with the "insert"
+ operation.
<type>
The number of rows in a table exceeds the maximum number
permitted by the table's "maxRows" value (see <table-schema>).
+ "error": "constraint violation"
+
+ Two or more rows in a table had the same values in the columns
+ that comprise an index.
+
+ "error": "resources exhausted"
+ "error": "I/O error"
+
+ As described in the definition of <error> above.
+
If "params" contains one or more "wait" operations, then the
transaction may take an arbitrary amount of time to complete. The
database implementation must be capable of accepting, executing, and
ongoing "monitor" request. No more "update" messages will be sent for
this table monitor.
+lock operations
+...............
+
+Request object members:
+
+ "method": "lock", "steal", or "unlock" required
+ "params": [<id>] required
+ "id": <nonnull-json-value> required
+
+Response object members:
+
+ "result": {"locked": <boolean>} for "lock"
+ "result": {"locked": true} for "steal"
+ "result": {} for "unlock"
+ "error": null
+ "id": same "id" as request
+
+Performs an operation on a "lock" object. The database server
+supports an arbitrary number of locks, each of which is identified by
+a client-defined id (given in "params"). At any given time, each lock
+may have at most one owner.
+
+The locking operation depends on "method":
+
+ - "lock": The database will assign this client ownership of the
+ lock as soon as it becomes available. When multiple clients
+ request the same lock, they will receive it in first-come, first
+ served order.
+
+ - "steal": The database immediately assigns this client ownership
+ of the lock. If there is an existing owner, it loses ownership.
+
+ - "unlock": If the client owns the lock, releases it. If the
+ client is waiting to obtain the lock, cancels the request and
+ stops waiting.
+
+ (Closing or otherwise disconnecting a database client connection
+ unlocks all of its locks.)
+
+For any given lock, the client must alternate "lock" or "steal"
+operations with "unlock" operations. That is, if the previous
+operation on a lock was "lock" or "steal", it must be followed by an
+"unlock" operation, and vice versa.
+
+For a "lock" operation, the "locked" member in the response object is
+true if the lock has already been acquired, false if another client
+holds the lock and the client's request for it was queued. In the
+latter case, the client will be notified later with a "locked" message
+when acquisition succeeds.
+
+These requests complete and send a response quickly, without waiting.
+The "locked" and "stolen" notifications (see below) report
+asynchronous changes to ownership.
+
+The scope of a lock is a database server, not a database hosted by
+that server. A naming convention, such as "<db-name>__<lock-name>",
+can effectively limit the scope of a lock to a particular database.
+
+locked
+......
+
+Notification object members:
+
+ "method": "locked"
+ "params": [<id>]
+ "id": null
+
+Notifies the client that a "lock" operation that it previously
+requested has succeeded. The client now owns the lock named in
+"params".
+
+The database server sends this notification after the reply to the
+corresponding "lock" request (but only if the "locked" member of the
+response was false), and before the reply to the client's subsequent
+"unlock" request.
+
+stolen
+......
+
+Notification object members:
+
+ "method": "stolen"
+ "params": [<id>]
+ "id": null
+
+Notifies the client that owns a lock that another database client has
+stolen ownership of the lock. The client no longer owns the lock
+named in "params". The client must still issue an "unlock" request
+before performing any subsequent "lock" or "steal" operation on the
+lock.
+
+If the client originally obtained the lock through a "lock" request,
+then it will automatically regain the lock later after the client that
+stole it releases it. (The database server will send the client a
+"locked" notification at that point to let it know.)
+
+If the client originally obtained the lock through a "steal" request,
+the database server won't automatically reassign it ownership of the
+lock when it later becomes available. To regain ownership, the client
+must "unlock" and then "lock" or "steal" the lock again.
+
echo
....
Provides information to a database administrator on the purpose of
a transaction. The OVSDB server, for example, adds comments in
transactions that modify the database to the database journal.
+
+assert
+......
+
+Request object members:
+
+ "op": "assert" required
+ "lock": <id> required
+
+Result object members:
+
+ none
+
+Semantics:
+
+ If the client does not own the lock named <string>, aborts the
+ transaction.
+
+Errors:
+
+ "error": "not owner"
+
+ The client does not own the named lock.
git://git.onelab.eu / sliver-openvswitch.git / blobdiff