Actually, now that I think about it, this is probably wrong. I'm reverting...

Chris Rossi

2009-07-22 b8e2b16985c7e5b4cabf87be73c6384266b8d3b6

Actually, now that I think about it, this is probably wrong.  I'm reverting
this change for now.

What I observed is that in a ZODB based app, the ZODB connection was closed
when I let the closer fall out of scope.  I see from examining the code, 
though, that this is a side effect of the environ that the closer hangs on
to getting deleted.  There is nothing here that pops the registry when the
closer is deleted.  You still have to call the closer for that to happen.

 repoze/bfg/scripting.py

@@ -4,12 +4,10 @@
    The ``root`` returned is the application root object.  The
    ``closer`` returned is a callable (accepting no arguments) that
    should be called when your scripting application is finished using
    the root.  The closer also closes the db connection when its ``__del__``
    method is called.  This means the connection can also be closed by 
    explicitly deleting the closer using ``del`` or, more commonly,  letting 
    it fall out of scope.  If ``environ`` is not None, it is used as the 
    environment passed to the BFG application root factory.  An empty environ 
    is constructed and passed to the root factory if ``environ`` is None."""
    the root.  If ``environ`` is not None, it is used as the
    environment passed to the BFG application root factory.  An empty
    environ is constructed and passed to the root factory if
    ``environ`` is None."""
    registry = app.registry
    threadlocals = {'registry':registry, 'request':None}
    app.threadlocal_manager.push(threadlocals)