the jython folks dont have such a reliable implementation of
__del__, and even if they did I can already tell people's mistrust on this one is going to make this inevitable. while
__del__ should remain as one way for connections to get returned to the pool, additionally add a counter to
Pool increment the counter when giving out a connection and have
ConnectionFairy decrement it when the close() method is called, then return to the pool when the counter hits zero.
so if things have been working for you with
__del__, theyll still work; but your app might not be very good in a Jython environment.
ResultProxy will have to enforce a close() method. The alternative, doing it automatically, would mean doing a close() on the last iteration, meaning the
RowProxy's it returns cant point to a "live" row and it would have to be copied into a buffer, at which point i definitely dont want to do that (i.e. add huge overhead to workaround an issue smaller than the overhead itself).
more tricky is a CRUD operation. Assuming you cant rely upon
__del__, youll now have to close() the result from an insert/update/delete:
r = table.update().execute() r.close()
if you are using explicit connections, i.e. these two not-yet-released styles:
then you can obviously just close the connection object you retrieved.
note that mapper operations process results fully, so the close() method will just be added internally to mapper methods and wont affect their usage.
additionally, SQLEngine will have to internally become connection aware...
SchemaIterator objects will have to pull their own connection out, hold onto it, and then have the
SchemaIterator be closed at the end of the operation. this also had to be added to various scalar() operations, default function executes, etc. the unittest suite should be enhanced to disable the
__del__ functionality, run the entire suite, and verify that connection counters operate properly...probably best acheived via a