Ищу готовую обёртку для QSqlDatabase или помощь в создании

Доброго времени суток.

В новом проекте появилась потребность в организации подключения к БД в отдельном потоке с возможностью использования оной в множестве других потоков.

Раньше данную задачу решали создание обертки работающий через сигналы и слоты с БД в другом потоке (либо без потока), но при этом не было потребностей организовывать доступ к одному конекту БД сразу из нескольких потоков.
Сейчас появилась потребность в переработке (написания с нуля) такой обертки которая позволит реализовать многопоточную работу с БД. При этом главным условием является использование только одного коннекта к БД без возможности создания множественных коннектов с теми же параметрами.
Следовательно возник вопрос: а нет ли уже готовых решений которые можно позаимствовать? Ну или может подскажете каким образом это проще реализовать для Qt?)

Заранее спасибо.

Готовых не знаю.
Но в принципе, если у вас уже есть фоновый объект работающий через сигналы, то достаточно обернуть его в еще один фоновый объект который будет заниматься очередью запросов.

White Owl,

Это первое, что пришло в голову. Но к сожалению такие обертки усложняют использование базового функционала QSqlQuery, по факту нужно написать аналог bind и bound.

heleo,
Готового не знаю, увы.
Доводилось руками делать нечто подобное.
Можно скооперироваться, если есть желание.
Мыло открыто, пиши.

rovan,

Спасибо за предложение. Но пока что поищу дальше, может чего нарыть получится.

heleo
Но к сожалению такие обертки усложняют использование базового функционала QSqlQuery, по факту нужно написать аналог bind и bound.

Вовсе нет.
Можно и без врапперов...

У тебя уже есть фоновая работа с БД? Как она организована?
Рабочий поток посылает в фоновый поток коннекта сообщение с sql запросом. Фоновый поток этот запрос отдает интерфейсному драйверу который и работает напрямую с СУБД. Дожидается ответа от этого интерфейсного драйвера и кидает рабочему потоку сигнал "готово". Потом по отдельному запросу отдает рабочему потоку резалтсет.
Так?

Теперь тебе достаточно в этот фоновый поток коннекта добавить индексированную очередь запросов. Тогда множество рабочих потоков смогут кидать запросы и получать в ответ индексы. Теперь объект работающий с СУБД может по очереди брать запросы из очереди, отправлять их в СУБД, а получив ответ ... Ну дальше уже варианты:
- кидать сигнал "готово" именно тому потоку который послал запрос (тогда при постановке запроса в очередь надо запоминать кто его послал).
- кидать широковещательный сигнал о готовности с добавлением в сигнал индекса. И рабочие потоки будут смотреть: мой индекс или не мой? Если мой - запрашивать резалтсет.

Ещё раз, переосмыслим...

heleo
В новом проекте появилась потребность в организации подключения к БД в отдельном потоке

Именно подключаться к БД в отдельном потоке бессмысленно, это быстро, делается один раз -- можно сделать это в главном потоке.
(main)

heleo
с возможностью использования оной в множестве других потоков.

Это уже более осмысленно, но соединение на время выполнения запроса всё равно будет занято, поэтому особенно эффективно разделять его не получится.

Лучше (на мой взглад) делать компоненту "пул соединений и очередь запросов на асинхронное выполнение в БД"

heleo
Сейчас появилась потребность в переработке (написания с нуля) такой обертки которая позволит реализовать многопоточную работу с БД. При этом главным условием является использование только одного коннекта к БД без возможности создания множественных коннектов с теми же параметрами.

Это какое-то странное условие. По коннекту на запрос создавать, конечно, глупо, но 5-10 коннектов вместо одного -- вовсе нет ничего страшного.

Ага, так и сделано, только основной поток он же GUI не сигнал ждет, а просто включает новый цикл обработки событий и холостит до сигнала завершения запроса.

White Owl

heleo Но к сожалению такие обертки усложняют использование базового функционала QSqlQuery, по факту нужно написать аналог bind и bound. Вовсе нет. Можно и без врапперов... У тебя уже есть фоновая работа с БД? Как она организована? Рабочий поток посылает в фоновый поток коннекта сообщение с sql запросом. Фоновый поток этот запрос отдает интерфейсному драйверу который и работает напрямую с СУБД. Дожидается ответа от этого интерфейсного драйвера и кидает рабочему потоку сигнал "готово". Потом по отдельному запросу отдает рабочему потоку резалтсет. Так? Теперь тебе достаточно в этот фоновый поток коннекта добавить индексированную очередь запросов. Тогда множество рабочих потоков смогут кидать запросы и получать в ответ индексы. Теперь объект работающий с СУБД может по очереди брать запросы из очереди, отправлять их в СУБД, а получив ответ ... Ну дальше уже варианты: - кидать сигнал "готово" именно тому потоку который послал запрос (тогда при постановке запроса в очередь надо запоминать кто его послал). - кидать широковещательный сигнал о готовности с добавлением в сигнал индекса. И рабочие потоки будут смотреть: мой индекс или не мой? Если мой - запрашивать резалтсет.

Это все хорошо до тех пор пока не появляется транзакция с begin, end и кучей запросов посередине в рамках работы одного из потоков, а следовательно тут не просто пул запросов и ответов по сигналам.

MasterZiv

Ещё раз, переосмыслим... heleo В новом проекте появилась потребность в организации подключения к БД в отдельном потоке Именно подключаться к БД в отдельном потоке бессмысленно, это быстро, делается один раз -- можно сделать это в главном потоке. (main) heleo с возможностью использования оной в множестве других потоков. Это уже более осмысленно, но соединение на время выполнения запроса всё равно будет занято, поэтому особенно эффективно разделять его не получится. Лучше (на мой взглад) делать компоненту "пул соединений и очередь запросов на асинхронное выполнение в БД" heleo Сейчас появилась потребность в переработке (написания с нуля) такой обертки которая позволит реализовать многопоточную работу с БД. При этом главным условием является использование только одного коннекта к БД без возможности создания множественных коннектов с теми же параметрами. Это какое-то странное условие. По коннекту на запрос создавать, конечно, глупо, но 5-10 коннектов вместо одного -- вовсе нет ничего страшного.

Ну тут по всей видимости я криво отписался. Конечно конект один на все время работы программы, создание нескольких конектов под одними и теми же параметрами login\password не допускается. Создается он по факту в main путем создания отдельного потока с БД.

heleo, ну как, нашел что-нибудь?