Alexander Kukushkin d8982e1e5a Refactor Postgresql.query method to use common 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 should retry only when connection is closed or broken.
BUT, the 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 addition to that I've changed most of the unit tests to use `Mock` and
`patch` where it is possible.

2015-09-20 13:54:30 +02:00

..

test_api.py

Refactor Postgresql.query method to use common retry mechanism

2015-09-20 13:54:30 +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 common retry mechanism

2015-09-20 13:54:30 +02:00

test_ha.py

Refactor Postgresql.query method to use common retry mechanism

2015-09-20 13:54:30 +02:00

test_patroni.py

Refactor Postgresql.query method to use common retry mechanism

2015-09-20 13:54:30 +02:00

test_postgresql.py

Refactor Postgresql.query method to use common retry mechanism

2015-09-20 13:54:30 +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 common retry mechanism

2015-09-20 13:54:30 +02:00

test_zookeeper.py

Refactor Postgresql.query method to use common retry mechanism

2015-09-20 13:54:30 +02:00