account and container database module common.db should use documented sqlite3 error codes instead of strings

[clayg]

We currently classify errors from the sqlite3 module talking to account and container databases by the error message string [1].

This is a terrible/brittle taxonomy and leads to mistakes/gaps [2].

According to the sqlite3 documentation there are broad catagories of error codes that would be wonderfully suited for the possibly_quarantine method [3], but they're apparently not availabe from CPython [4, 5, 6].

1. https://github.com/openstack/swift/blob/43a175ebd284e825c0f6e5b79a23d8a32f62326e/swift/common/db.py#L325
2. e.g. lp bug #1646247
3. https://www.sqlite.org/rescode.html
4. https://github.com/python/cpython/blob/3de470284c2e067ae445c572413a0290d58fb139/Modules/_sqlite/util.c#L87
5. http://stackoverflow.com/questions/25371636/how-to-get-sqlite-result-error-codes-in-python
6. https://bugs.python.org/issue16379

[Tim Burke (1-tim-z)]

So what's the scope involved here? Patch Python to do something better with error codes, then move Swift to only support py36+? Roll our own (C-based?) SQLite lib?

I agree that the current situation isn't great, but I'm not really seeing a better way forward. *Maybe* we could look for some particular instances (IntegrityError, maybe? Given that DatabaseError is the default, that seems too broad... we *have* to go digging through strings)

Meanwhile, by falling back to reraising, we get noisy logs that prompt us to shore up the gaps pretty quickly when they come up. Three days from bug report to fix merged seems not bad... I kinda wanna just close as Won't Fix.