Comments 5
Советую добавить чуть более подробное описание на GitHub и отправить проект в каталог inqlude.org
Спасибо, полезная вещь, но есть пара вопросов:
- Извлечь указатель на sqlite3* из QVariant можно и через обычный static_cast, что, кстати, и рекомендуется в приведенной вами ссылке на документацию. Почему извлекаете именно через макросы Q_DECLARE_*?
- В связи с чем связано использование классов std::mutex и std::lock_quard, если существуют аналогичные в Qt QMutex и QMutexLocker? Если дело в накладных расходах, то, возможно, стоило бы использовать и std::ofstream вместо QFile.
1. Макросы связаны с тем, что использую метод value, который делает qvariant_cast. Метод data присутствует, но он помечен как «internal» и в документацию не попадает, поэтому использовал value.
2. Ничем. Отдаю предпочтение стандартным типам, да и код там тривиальный.
2. Ничем. Отдаю предпочтение стандартным типам, да и код там тривиальный.
Отличный хинт. Если опишите такое же для mysql и postgre я думаю многие скажут вам большое спасибо.
Есть небольшой комментарий:
Я не видел конкретной реализации функции которая вызывает «profile», но есть вероятность что в userData вам может прийти чужой указатель (например ваша библиотека/плагин одна/один из многих использующих sqlite с профилированием в приложении), и слепой static_cast может тут немного попортить нервы. Наверно я бы сделал profile статическим методом синглтона Log и добавил проверку на равенство userData. Есть подозрение что по userData реализовали разделение профилируемых запросов на стороне «клиента» (может быть я ошибаюсь не очень представляю схему по которой реализованы подключения в sqlite из одного процесса.). Просто неоднократно сталкивался с подобным дизайном в C API.
Есть небольшой комментарий:
Я не видел конкретной реализации функции которая вызывает «profile», но есть вероятность что в userData вам может прийти чужой указатель (например ваша библиотека/плагин одна/один из многих использующих sqlite с профилированием в приложении), и слепой static_cast может тут немного попортить нервы. Наверно я бы сделал profile статическим методом синглтона Log и добавил проверку на равенство userData. Есть подозрение что по userData реализовали разделение профилируемых запросов на стороне «клиента» (может быть я ошибаюсь не очень представляю схему по которой реализованы подключения в sqlite из одного процесса.). Просто неоднократно сталкивался с подобным дизайном в C API.
Sign up to leave a comment.
Профилирование запросов к SQLite для Qt приложений