Alexander Kukushkin 9f9cb6005d Refactor Postgresql.query method to use commont retry mechanism ...

query method in an api.py also needs retry in some cases (for example
when we are running is_healthiest_node check).
In all cases We will retry only when connection is closed or broken, BUT
connection status must be checked via cursor.connection (old
implementation was using general connection object for that). For
multi-threaded applications this is not appropriate, because some other
thread might restore connection.

In appdition to that I've changed most of the unit tests to use `Mock` and
`patch` where it is possible.

2015-09-20 13:41:57 +02:00

..

test_api.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00

test_aws.py

Refactor directory structure in preparation for building pypi-package

2015-09-04 16:06:44 +02:00

test_etcd.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00

test_ha.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00

test_patroni.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00

test_postgresql.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00

test_restore.py

Refactor directory structure in preparation for building pypi-package

2015-09-04 16:06:44 +02:00

test_utils.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00

test_zookeeper.py

Refactor Postgresql.query method to use commont retry mechanism

2015-09-20 13:41:57 +02:00