It is useful to make the notification events that Idl processes
accessible to users of the library. This will make it possible to
keep external systems in sync, but does not impose any particular
notification pattern.
The Row.from_json() call is added to be able to convert the 'old'
JSON response on an update to a Row object to make it easy for
users of notify() to see what changed, though this usage of Row
is quite different than Idl's typical use.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Row.delete() handled the case of deleting a row that was added within the
current transaction, but not yet committed, but it did not correctly handle
the case of deleting a row that belonged to the database before the
transaction started. This fixes the problem.
Reported-by: Yeming Zhao <zhaoyeming@gmail.com>
Tested-by: Yeming Zhao <zhaoyeming@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
In some cases getattr(Row instance, attrname) doesn't raise AttributeError,
but TypeError
> File "python/ovs/db/idl.py", line 554, in __getattr__
> datum = self._data[column_name]
> TypeError: 'NoneType' object has no attribute '__getitem__'
So getattr(Row instance, attrname, default value) doesn't work.
This occurs when row._changes doesn't include attrname and row._data is None.
So teach Row.__getattr__ _data=None case.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Since Transaction._substitute doesn't substitute elements of list/tuple,
setting list references results in transaction error. Teach it such case.
Example:
{"op": "update",
"row":{"bridges":["set",[["uuid",
"1f42bc19-307f-42e7-a9c0-c12178bd8b51"],
["uuid",
"f97e0c76-7146-489d-9bed-29bc704f65fe"]]]},
"table": "Open_vSwitch",
"where":[["_uuid", "==", ["uuid",
"20c2a046-ae7e-4453-a576-11034db24985"]]]}
In the above case, uuid in "row" aren't replaced by "named-uuid" because
the function doesn't look into elements of lists.
When list/tuple is found, look into elements recursively.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is needed when using schema that was retrieved from ovsdb by get_schema
method.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add register_table method to SchemaHelper as Python counterpart of
ovsdb_idl_add_table() in the C version of the IDL.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Originally the IDL transaction state machine had a return value
TXN_TRY_AGAIN to signal the client to wait for a change in the database and
then retry its transaction. However, this logic was incomplete, because
it was possible for the database to change before the reply to the
transaction RPC was received, in which case the client would wait for a
further change. Commit 4fdfe5ccf8 (ovsdb-idl: Prevent occasional hang
when multiple database clients race.) fixed the problem by breaking
TXN_TRY_AGAIN into two status codes, TXN_AGAIN_WAIT that meant to wait for
a further change and TXN_AGAIN_NOW that meant that a change had already
occurred so try again immediately.
This is correct enough, but it is more complicated than necessary. It is
simpler and just as correct to use a single "try again" status that
requires the client to wait for a change relative to the database contents
*before* the transaction was committed. This commit makes that change.
It also changes ovsdb_idl_run()'s return type from bool to void because
its return type is hardly useful anymore.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The recently added SchemaHelper class significantly simplifies IDL
instantiation in Python. This commit converts all users of the old
method to the new method, and removes support for the old method.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
When a client of the IDL tries to commit a read-modify-write transaction
but the database has changed in the meantime, the IDL tells its client to
wait for the IDL to change and then try the transaction again by returning
TXN_TRY_AGAIN. The "wait for the IDL to change" part is important because
there's no point in retrying the transaction before the IDL has received
the database updates (the transaction would fail in the same way all over
again).
However, the logic was incomplete: the database update can be received
*before* the reply to the transaction RPC (I think that in the current
ovsdb-server implementation this will always happen, in fact). When this
happens, the right thing to do is to retry the transaction immediately;
if we wait, then we're waiting for an additional change to the database
that may never come, causing an indefinite hang.
This commit therefore breaks the "try again" IDL commit status code
into two, one that means "try again immediately" and another that means
"wait for a change then try again". When an update is processed after a
transaction is committed but before the reply is received, the "try again
now" tells the IDL client not to wait for another database change before
retrying its transaction.
Bug #5980.
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
Reproduced-by: Alex Yip <alex@nicira.com>
This patch does minor style cleanups to the code in the python and
tests directory. There's other code floating around that could use
similar treatment, but updating it is not convenient at the moment.
Until now, the Python bindings for OVSDB have not supported writing to the
database. Instead, writes had to be done with "ovs-vsctl" subprocesses.
This commit adds write support and brings the Python bindings in line with
the C bindings.
This commit deletes the Python-specific IDL tests in favor of using the
same tests as the C version of the IDL, which now pass with both
implementations.
This commit updates the two users of the Python IDL to use the new write
support. I tested this updates only by writing unit tests for them,
which appear in upcoming commits.
According to Reid, there may be some disadvantages to having this class be
anonymous, for example, cannot do instance/typechecking, might be
allocating a new class for every row as well, which isn't the most memory
efficient.
Suggested-by: Reid Price <reid@nicira.com>
Idl.__parse_row_update() assumed that every change that the database server
sent down actually modified the database. This is generally true, but
since Idl.__modify_row() already returns whether there was a change, we
might as well use it.
Reported-by: Reid Price <reid@nicira.com>
Strangely malformed <row-update>s could hypothetically get confusing error
message. Using the Parser class should avoid that.
Reported-by: Reid Price <reid@nicira.com>
This leaves one use of __dict__ used for iterating through attributes.
I could use dir() instead, but I was put off by this note in its
documentation in the Python Library Reference:
Because dir() is supplied primarily as a convenience for use at an
interactive prompt, it tries to supply an interesting set of names more
than it tries to supply a rigorously or consistently defined set of names,
and its detailed behavior may change across releases. For example,
metaclass attributes are not in the result list when the argument is a
class.
Suggested-by: Reid Price <reid@nicira.com>
These initial bindings pass a few hundred of the corresponding tests
for C implementations of various bits of the Open vSwitch library API.
The poorest part of them is actually the Python IDL interface in
ovs.db.idl, which has not received enough attention yet. It appears
to work, but it doesn't yet support writes (transactions) and it is
difficult to use. I hope to improve it as it becomes clear what
semantics Python applications actually want from an IDL.
