Я изучаю Google App Engine и пытаюсь найти подходящий подход к управлению подключением базы данных к экземпляру Google Cloud SQL (если вы не использовали GC-SQL, в основном это MySQL в облаке, несколько ограничений).Что такое хороший подход к управлению соединением db в приложении Python Google Cloud SQL (GAE)?
Я использую среду GAE python (2.7) с инфраструктурой webapp2 для обработки запросов. Я знаю, что в FAQ говорится, что с каждым запросом рекомендуется создать новое соединение с БД, но я не знаю, какой рекомендуемый способ закрыть соединение. Каждый раз, когда я пытаюсь удалить таблицы во время разработки, GC-SQL зависает, и «show processlist» показывает, что существует множество процессов (вероятно, из-за того, что я не закрываю DB) и что один из них ждет блокировки (вероятно, процесс, пытающийся отбросить таблицы). Это раздражает и заставляет меня перезапустить экземпляр GC-SQL (например, перезапустить службу mysql-сервера, я полагаю). Есть также случайные икоты DB, которые, я считаю, связаны с тем фактом, что я действительно не закрываю свое соединение с БД.
Так, например, должен ли я иметь деструктор моего экземпляра подкаталога webapp2.Requesthandler для отключения от БД? Объекты GAE, похоже, иногда кэшируются, так что это тоже нужно рассмотреть. Полагаю, я мог бы просто подключиться/запросить/отключиться для каждого запроса, но это кажется субоптимальным.
Я знаю, что это неопределенный вопрос, но я надеюсь, что кто-то, кто играл в этой области, может пробраться несколько советов по моему пути.
Заранее благодарен!
Обновление: Я попытался реализовать оболочку вокруг методов, которым нужен курсор, используя ответ Шая в качестве отправной точки. Я получаю ошибки GAE. Вот новый вопрос, связанный с этим: What are the connection limits for Google Cloud SQL from App Engine, and how to best reuse DB connections?
Спасибо Гвидо. Я смирен. К сожалению, webapp2, который является базой WSGI, которую я использую в GAE, похоже, не включает оболочку API DB. Я слишком глубоко разбираюсь в своем проекте и не спеша реорганизую его для другой структуры. Итак, я завязал управление соединением DB вручную. Любые другие намеки? :-) Еще раз спасибо за ваше время. – JJC
Я не уверен, что понимаю - мое предложение состоит в том, что вы сами пишете крошечную часть связующего ПО WSGI, которая открывает и закрывает соединение с БД. Это по-прежнему для меня руководство (поскольку вы пишете код) и не кажется несовместимым с webapp2, который, как вы говорите, совместим с WSGI. Что мне не хватает? (OTOH декоратор кажется прекрасной идеей тоже.) –
Ahhh. Сожалею. Я совершенно не знаком с веб-разработчиком с python, и теперь понимаю, что я действительно не понял ваш ответ раньше. :-) Теперь, когда я посмотрел и понял, что «WSGI middlware»! = Веб-фреймворк, совместимый с WSGI, имеет смысл. Фильтр/промежуточное ПО WSGI, который обертывает webapp2.RequestHandler для подключения, а затем позже отключается от БД, по вашему мнению, имеет смысл и находится в духе ответа Шей. Благодаря! – JJC