[ZODB-Dev] Connection simplification

[Tim Peters]

[Tim Peters, on the consequences of connection simplification]
>> So if your goal is "can't block", it meets that goal as-is.

[Syver Enstad]
> That sounds good. Together with the logging of using too many connections
> that sounds okay, even if a hard error can be better in that it is more
> visible, logging is probably the more correct way to report using too
> many connections.

Would you like a hard error?  You didn't get one before (DB.open() returned
None or hung).  Python's logging module gives me a headache, but it's so
elaborate it *may* be possible to insert a logging handler that triggers
propagated exceptions for specific log messages.  If possible, that's the
kind of general approach I'd rather take than adding optional arguments /
config knobs all over the place.

>> It's certainly possible to hack things in 3.4 so that
>> DB.open(waitflag=False) would continue to return None sometimes.
>>
>> I think that's ugly, but I'll do it if I have to (the ZODB APIs are
>> choked with "convenience gimmicks" that are unclear, undocumented, &
>> untested;

> Don't hack it Tim. I wholeheartedly agree with you that the code needs
> cleanup, and the situation you have described with an "unlimited" pool
> but logging "too many" connections sounds good enough for me.

That's great, but feel free to change your mind <wink>.  This is implemented
on the ZODB trunk now, so you could try it now from a checkout, or wait for
a ZODB 3.4a1 release (sorry, I have no estimate yet for when that may
happen):

    svn.zope.org/repos/main/ZODB/trunk

Restoring usable semantics for waitflag=False would be a simple change, and
I won't object if it would really help you.  "The problems" here were
emergent, after dozens and dozens of "simple changes" got slammed in without
docs or tests (or, in most cases, even code comments), until in aggregate
they buried the code's original intents under mountains of optional
behaviors nobody understands anymore.  If I put waitflag back in, it will be
documented, and it will be tested.

IOW, I really don't want to take away something that's *useful* to you.  I
want to get rid of the accumulated cruft that appears not to be used by
anyone anymore, and there's plenty of that to make a real improvement.