[CalendarServer-changes] [11733] CalendarServer/trunk/twext/enterprise/test/test_adbapi2.py
source_changes at macosforge.org
source_changes at macosforge.org
Tue Sep 17 16:41:32 PDT 2013
Revision: 11733
http://trac.calendarserver.org//changeset/11733
Author: glyph at apple.com
Date: 2013-09-17 16:41:32 -0700 (Tue, 17 Sep 2013)
Log Message:
-----------
a few more coding-standard fixes for the test module.
Modified Paths:
--------------
CalendarServer/trunk/twext/enterprise/test/test_adbapi2.py
Modified: CalendarServer/trunk/twext/enterprise/test/test_adbapi2.py
===================================================================
--- CalendarServer/trunk/twext/enterprise/test/test_adbapi2.py 2013-09-17 23:08:55 UTC (rev 11732)
+++ CalendarServer/trunk/twext/enterprise/test/test_adbapi2.py 2013-09-17 23:41:32 UTC (rev 11733)
@@ -300,8 +300,8 @@
def test_stopServiceWithSpooled(self):
"""
When L{ConnectionPool.stopService} is called when spooled transactions
- are outstanding, any pending L{Deferreds} returned by those transactions
- will be failed with L{ConnectionError}.
+ are outstanding, any pending L{Deferreds} returned by those
+ transactions will be failed with L{ConnectionError}.
"""
# Use up the free slots so we have to spool.
hold = []
@@ -450,7 +450,8 @@
stopResult = self.resultOf(self.pool.stopService())
# Sanity check that we haven't actually stopped it yet
self.assertEquals(abortResult, [])
- # We haven't fired it yet, so the service had better not have stopped...
+ # We haven't fired it yet, so the service had better not have
+ # stopped...
self.assertEquals(stopResult, [])
d.callback(None)
self.flushHolders()
@@ -553,10 +554,11 @@
def test_reConnectWhenFirstExecFails(self):
"""
- Generally speaking, DB-API 2.0 adapters do not provide information about
- the cause of a failed 'execute' method; they definitely don't provide it
- in a way which can be identified as related to the syntax of the query,
- the state of the database itself, the state of the connection, etc.
+ Generally speaking, DB-API 2.0 adapters do not provide information
+ about the cause of a failed 'execute' method; they definitely don't
+ provide it in a way which can be identified as related to the syntax of
+ the query, the state of the database itself, the state of the
+ connection, etc.
Therefore the best general heuristic for whether the connection to the
database has been lost and needs to be re-established is to catch
@@ -564,8 +566,8 @@
transaction.
"""
# Allow 'connect' to succeed. This should behave basically the same
- # whether connect() happened to succeed in some previous transaction and
- # it's recycling the underlying transaction, or connect() just
+ # whether connect() happened to succeed in some previous transaction
+ # and it's recycling the underlying transaction, or connect() just
# succeeded. Either way you just have a _SingleTxn wrapping a
# _ConnectedTxn.
txn = self.createTransaction()
@@ -636,8 +638,8 @@
"""
class BindingSpecificException(Exception):
"""
- Exception that's a placeholder for something that a database binding
- might raise.
+ Exception that's a placeholder for something that a database
+ binding might raise.
"""
def alsoFailClose(factory):
factory.childCloseWillFail(BindingSpecificException())
@@ -738,8 +740,8 @@
therefore pointless, and can be ignored. Furthermore, actually
executing the commit and propagating a possible connection-oriented
error causes clients to see errors, when, if those clients had actually
- executed any statements, the connection would have been recycled and the
- statement transparently re-executed by the logic tested by
+ executed any statements, the connection would have been recycled and
+ the statement transparently re-executed by the logic tested by
L{test_reConnectWhenFirstExecFails}.
"""
txn = self.createTransaction()
@@ -758,12 +760,12 @@
def test_reConnectWhenSecondExecFailsThenFirstExecFails(self):
"""
- Other connection-oriented errors might raise exceptions if they occur in
- the middle of a transaction, but that should cause the error to be
- caught, the transaction to be aborted, and the (closed) connection to be
- recycled, where the next transaction that attempts to do anything with
- it will encounter the error immediately and discover it needs to be
- recycled.
+ Other connection-oriented errors might raise exceptions if they occur
+ in the middle of a transaction, but that should cause the error to be
+ caught, the transaction to be aborted, and the (closed) connection to
+ be recycled, where the next transaction that attempts to do anything
+ with it will encounter the error immediately and discover it needs to
+ be recycled.
It would be better if this behavior were invisible, but that could only
be accomplished with more precise database exceptions. We may come up
@@ -780,9 +782,9 @@
self.assertEquals(self.factory.connections[0].executions, 2)
# Reconnection should work exactly as before.
self.assertEquals(self.factory.connections[0].closed, False)
- # Application code has to roll back its transaction at this point, since
- # it failed (and we don't necessarily know why it failed: not enough
- # information).
+ # Application code has to roll back its transaction at this point,
+ # since it failed (and we don't necessarily know why it failed: not
+ # enough information).
self.resultOf(txn.abort())
self.factory.connections[0].executions = 0 # re-set for next test
self.assertEquals(len(self.factory.connections), 1)
@@ -888,7 +890,7 @@
self.assertEquals(len(e), 1)
- def test_twoCommandBlocks(self, flush=lambda : None):
+ def test_twoCommandBlocks(self, flush=lambda: None):
"""
When execution of one command block is complete, it will proceed to the
next queued block, then to regular SQL executed on the transaction.
@@ -932,9 +934,9 @@
def test_commandBlockDelaysCommit(self):
"""
Some command blocks need to run asynchronously, without the overall
- transaction-managing code knowing how far they've progressed. Therefore
- when you call {IAsyncTransaction.commit}(), it should not actually take
- effect if there are any pending command blocks.
+ transaction-managing code knowing how far they've progressed.
+ Therefore when you call {IAsyncTransaction.commit}(), it should not
+ actually take effect if there are any pending command blocks.
"""
txn = self.createTransaction()
block = txn.commandBlock()
@@ -1078,8 +1080,8 @@
def pump(self):
"""
- Deliver all input from the client to the server, then from the server to
- the client.
+ Deliver all input from the client to the server, then from the server
+ to the client.
"""
a = self.moveData(self.c2s)
b = self.moveData(self.s2c)
@@ -1185,5 +1187,3 @@
verifyObject(IAsyncTransaction, txn)
self.pump.flush()
self.assertEquals(len(self.factory.connections), 1)
-
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20130917/9866fbd5/attachment.html>
More information about the calendarserver-changes
mailing list