Fix for #230 Error due to non-existing table #235
Conversation
| monitored=True)) | ||
| except DBError: | ||
| # We can fail if the tables are not yet there | ||
| pass | ||
|
|
||
| op.drop_table('aim_vmm_domains') |
There was a problem hiding this comment.
wouldn't this fail too if the table didn't exist? Also, why wouldn't the table exist? It is created by a previous revision (1249face3348)
There was a problem hiding this comment.
The bug has two aspects:
Problem 1.
As described in the Issue #230, there is a new connection created by aceb1ac13668 before the commit of the earlier transactions started by the previous session. Since these transactions were not committed, the SQL statement creating the table did not commit too. You can refer to the SQL output attached here: https://github.com/noironetworks/aci-integration-module/files/2206403/postgresql.log-201806211158.txt.
Problem 2.
Looking at the logic in aceb1ac13668_vmm_policy.py, it is trying to fetch data from the previous schema and populating into the new schema. This logic could work well for existing table. In fact, the above issue (1) does not affect operation since a table from previous deployment already exists. But for a fresh deployment, the old schema tables do not exist and will be created fresh during migration which is not happening due to (1).
Solution:
The solution in this commit is to ignore failure to read the old tables. If tables do not exist, the queries will result in a DBError exception which we catch and ignore.
Hope this explanation helps.
Fixes: #230
The session handling is covered under try...except so that when the migration is done on a clean setup without pre-existing tables, it can pass through and not throw errors due to non-existing tables. If it is a pre-existing setup, then the tables will exist and the control goes through the try... section.