Смотри, лор, есть соединение до базы Connection, а также тип представляющий запрос Statement
data Connection
data Statement
Не будем вдаваться в подробности устройства этих типов. Важно только что они хранят MVar на состояние соединения и запроса соответственно. Над Connection есть методы
disconnect :: Connection -> IO ()
prepare :: Connection -> Query -> IO Statement
connStatus :: Connection -> IO ConnStatus
Полый список опять же не важен. И методы над Statement:
finish :: Statement -> IO ()
statementStatus :: Statement -> IO StatementStatus
Полный список тоже не важен.
Теперь представим, что мы наделали много Statement из одного Connection, и закрыли соединение (disconnect). Работа со Statement при закрытом соединении не возможна, это понятно. Возникает вопрос: должен ли метод disconnect автоматически закрывать все Statement (finish) перед самим дисконнектом, или нет? Если да, то как это лучше сделать?
Если использовать ResourceT, то правильный порядок освобождения ресурсов не гарантируется, так? Значит надо как-то это обрабатывать, либо в методе finish проверять состояние Connection перед финализацией Statement, и ничего не делать, если соединение уже закрыто (в этом случае клиентская библиотека уже очистила все дочерние запросы сама). Либо хранить в Connection список ленивых ссылок на все дочерние Statement и финализировать их перед disconnect в обязательном порядке.
Жду советов, вобщем.