IRC log of #zodb for Thursday, 2016-06-30

jamaddenA ZODB Connection is documented as not being thread-safe and must be used only by a single thread at a time. In IMVCC, each Connection has a unique storage object. So the storage object is used only by a single thread. So there's really not much point in RelStorage keeping thread locks around its methods, is there?00:01
jamaddenThere are a tiny handful (8) of ZODB test cases that assume the storage is thread safe, but other than that I don't see any problems00:41
*** J1m has quit IRC01:03
*** J1m has joined #zodb01:11
*** J1m has quit IRC01:33
*** jamadden has quit IRC04:59
*** J1m has joined #zodb06:18
*** J1m has quit IRC06:36
*** jensens has joined #zodb10:19
*** jamadden has joined #zodb10:46
*** J1m has joined #zodb15:33
*** povbot has joined #zodb16:04
*** jensens has quit IRC21:37
jamaddenThe changed method signature of ZODB.tests.ConflictResolution.ConflictResolvingStorage.checkResolve()  in 4.4.0 broke RelStorage tests. 😢22:13
jamaddenit's not a big deal, just surprising.22:14
J1mThat's weird. It looks backward compatible to me.22:17
J1mThe old function took no arguments and demonstrated handling of a resolvable conflict.22:17
J1mThe new function takes a resolvable argument that defaults to true.22:18
jamaddenWe override checkResolve(self), and but line 90 in checkUnresolvable calls self.checkResolve(False)22:18
jamaddenI think we mean 'resolve' in different ways22:18
jamaddenso the RelStorage function was unintentionally, as far as I can see, shadowing the ZODB function22:19
J1mThis is why inheritance interface is an oxymoron.22:19
jamaddenI figure that since RS 2.0b1 *just* came out and bumped the min supported ZODB version to 4.3, there won't be any problem if 2.0b2 goes right ahead and bumps it to 4.4 and implements the new protocol22:27

Generated by 2.15.1 by Marius Gedminas - find it at!