forum.opennet.ru - "Доступен Pgfe 2, клиентский C++ API к PostgreSQL" (23)

"Доступен Pgfe 2, клиентский C++ API к PostgreSQL"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Доступен Pgfe 2, клиентский C++ API к PostgreSQL"	+/–
Сообщение от opennews (??), 18-Апр-22, 22:05
Опубликован первый стабильный выпуск Pgfe 2 (PostGres FrontEnd), продвинутого и многофункционального драйвера (клиентский API) для PostgreSQL, написанного на языке C++ и упрощающего работу с PostgreSQL в проектах на C++. Код проекта распространяется под лицензией Apache 2.0. Для сборки требуется компилятор с поддержкой стандарта C++17... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57039
Ответить \| Правка \| Cообщить модератору

Оглавление

Есть сравнение с libpqxx , Аноним (1), 22:05 , 18-Апр-22, (1)

libpq на чистом C очень простая, приятная и удобная в работе вещь Забудь про би, Аноним (8), 02:51 , 19-Апр-22, (8) +3

Без классов - не по феншую , Аноним (17), 12:18 , 19-Апр-22, (17)

Реализации классов типа DBconnection dataset поверх чисто сишной libpq получаютс, Аноним (26), 21:20 , 19-Апр-22, (26)
ООП плохо стыкуется с базами данных Причем на всех уровнях -- от ISAM, что вниз, adolfus (ok), 02:10 , 23-Апр-22, (30)

Если вкратце, то Pgfe предоставляет гораздо более богатый набор возможностей, со, dmitigr (ok), 17:20 , 19-Апр-22, (20) +4

Скрыто модератором, Аноним (5), 23:38 , 18-Апр-22, (5) –9

Скрыто модератором, Аноним (6), 01:13 , 19-Апр-22, (6) –7

Скрыто модератором, Заноним (?), 02:50 , 19-Апр-22, (7) +1
Скрыто модератором, aaaaa (?), 02:55 , 19-Апр-22, (9) +2
Скрыто модератором, Аноним (12), 07:49 , 19-Апр-22, (12)

Скрыто модератором, Аноним (13), 07:51 , 19-Апр-22, (13)

Когда-то писал свой драйвер Postges для C Подключение было неблокирующее по б, Аноним (10), 03:14 , 19-Апр-22, (10) +2
как в сравнении с yandex ozo , aaaaa (?), 04:24 , 19-Апр-22, (11) +1

Гораздо больше возможностей В версии 2 1 будет добавлен API асинхронного ввода , dmitigr (ok), 17:27 , 19-Апр-22, (21) +1

Дмитрий, приветствую Спасибо за обратную связь Поддержка asio была бы замечател, aaaaa (?), 18:42 , 19-Апр-22, (22)

Постараюсь добавить поддержку ASIO Issue по данной задаче -- https github com, dmitigr (ok), 19:44 , 19-Апр-22, (23) +1

Как ни крути, а библиотеки должны быть с сишным интерфейсом , Аноним (-), 08:11 , 19-Апр-22, (14) +3

Прикол в том, что для конечного программиста максимально удобной является обертк, Аноним (15), 10:25 , 19-Апр-22, (15) –4

Для этого есть Qt Но есть нюанс , Аноним (16), 10:32 , 19-Апр-22, (16)
Ты путаешь язык и парадигму ООПить можно хоть на ассемблере , Аноним (12), 13:57 , 19-Апр-22, (19)
Удобство это только одна сторона медали , Аноним (-), 19:58 , 19-Апр-22, (24)
Вам так часто нужно наследование , Аноним (-), 19:59 , 19-Апр-22, (25)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 18-Апр-22, 22:05 +/–

Есть сравнение с libpqxx?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #20

5. Сообщение от Аноним (5), 18-Апр-22, 23:38 –9 +/–

Второй тред этой темы что Постгря УГ. Даже яндекс еда работает на MySQL. Постргря безнадежно отстала в накручивании своих ненужных фич.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #13

6. Сообщение от Аноним (6), 19-Апр-22, 01:13 –7 +/–

Меня в постгре больше всего убило, что нельзя просто взять psql и соединиться с какой-нибудь удаленной постгрей. Версия должна совпадать, иначе она отказывается работать. Версия обязательно не совпадет. На локалхосте у вас одна, на проде или стейдже - другая. В конце концов получается, что нужно звонить по ссш на хост и там локально коннектиться к постгре с помощью psql который с ней заведомо совместим. MySQL между версиями 5.7 и 5.6 серьезно отличается, однако клиент работает между ними без проблем.
Куча эндемичных для постгри способов написать запрос, которые надо помнить. Постгре авторитарно замыкает программиста на себя, тогда как мускля покупает его своей простотой и понятностью, которую даже не осознаешь, пока не столкнешься с постгредебилизмом!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #7, #9, #12

7. Сообщение от Заноним (?), 19-Апр-22, 02:50 +1 +/–

Ты какую-то дичь нагнал, psql обычно подключается даже старый клиент к новым серверам, просто warning'и накидывает.
А вот pg_dump/pg_restore да, защищают от глупых действий.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

8. Сообщение от Аноним (8), 19-Апр-22, 02:51 +3 +/–

libpq на чистом C очень простая, приятная и удобная в работе вещь! Забудь про биндинги к плюсам (за исключением универсальных либ с возможностью поменять драйвер СУБД), там сложнее и хуже.
P.S. Я серьезно, постгрес один из немногих случаев, когда сразу сделано нормально и удобно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17

9. Сообщение от aaaaa (?), 19-Апр-22, 02:55 +2 +/–

болеешь?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

10. Сообщение от Аноним (10), 19-Апр-22, 03:14 +2 +/–

Когда-то писал свой драйвер Postges для C++. Подключение было неблокирующее по бинарному протоколу с динамической генерацией конвертации из бинарных данных Postgres в переменные C++ и обратно. С помощью шаблонов во время компиляции определялся тип переменной C++, а во время рантайма запрашивались типы полей в базе. Так становилось понятно, какие типы куда конвертировать. Далее генерировались функции преобразования из, например, PG:bigint в C++:int32 для ответов и обратно для запросов. Для этого изначально компилировался объектник с разными преобразованиями и из него в mmaped память копировались тела нужных функций в нужном порядке с релокациями (в результате для преобразования нужно было обратиться к одной большой функции конвертации через указатель - остальное линейный код, т.е. для select bigint, real, varchar в int, float, string генерировалась фукнция преобразования трех переменных из байтового массива, пришедшего от Postgres). Делается через mmap(), запись туда кода, mprotect(m, size, PROT_READ | PROT_EXEC) и вызов кода по указателю (в общем, все, как в Java/UPX).
Забурился на том, что для генерации работы с std::string пришлось разбираться, что делать с исключениями (а там не просто скопировать сишную функцию с релокацией, там еще нужно обеспечить раскрутку стека, если, например, создание строки бросит исключение).
P.S. Конвейерная передача запросов (pipeline) имеет жесткое и неприятное ограничение - в случае ошибки в одном запросе все последующие отменяются и это нужно отслеживать.

Ответить | Правка | Наверх | Cообщить модератору

11. Сообщение от aaaaa (?), 19-Апр-22, 04:24 +1 +/–

как в сравнении с yandex/ozo?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21

12. Сообщение от Аноним (12), 19-Апр-22, 07:49 +/–

> нельзя просто взять psql и соединиться с какой-нибудь удаленной постгрей
Ты грибов из яндекс еды (собеседника выше) наелся?!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

13. Сообщение от Аноним (13), 19-Апр-22, 07:51 +/–

Очень толстый вброс.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

14. Сообщение от Аноним (-), 19-Апр-22, 08:11 +3 +/–

Как ни крути, а библиотеки должны быть с сишным интерфейсом.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

15. Сообщение от Аноним (15), 19-Апр-22, 10:25 –4 +/–

Прикол в том, что для конечного программиста максимально удобной является обертка в ООП, причем даже визуальное или полу-визуальное. Фиг знает, как это правильно объяснить. Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП. Оно естественное чисто потому, что так тупо будет меньше кода. А количество кода = трудозатраты программиста. Так зачем каждый раз изобретать велосипед? Именно поэтому мне нравится идея Delphi/Lazarus и очень жаль, что для C++ нет свободной альтернативы C++ Builder.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #16, #19, #24, #25

16. Сообщение от Аноним (16), 19-Апр-22, 10:32 +/–

Для этого есть Qt. Но есть нюанс :]

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Аноним (17), 19-Апр-22, 12:18 +/–

>Забудь про биндинги к плюсам
Без классов - не по феншую.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #26, #30

19. Сообщение от Аноним (12), 19-Апр-22, 13:57 +/–

> максимально удобной является обертка в ООП
Ты путаешь язык и парадигму. ООПить можно хоть на ассемблере.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

20. Сообщение от dmitigr (ok), 19-Апр-22, 17:20 +4 +/–

Если вкратце, то Pgfe предоставляет гораздо более богатый набор возможностей, современней и является отечественным ПО ;-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

21. Сообщение от dmitigr (ok), 19-Апр-22, 17:27 +1 +/–

Гораздо больше возможностей. В версии 2.1 будет добавлен API асинхронного ввода/вывода на базе обратных вызовов, что позволит использовать Pgfe в приложениях с циклом событий на базе разных его реализаций (в первую очередь, на базе libuv, но, вероятно, будет и поддержка ASIO, как в Ozo).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #22

22. Сообщение от aaaaa (?), 19-Апр-22, 18:42 +/–

Дмитрий, приветствую! Спасибо за обратную связь!
Поддержка asio была бы замечательным дополнением.
Я в своем web frameworkе использую boost.asio + boost.beast и в качестве backendа для pgsql ковыряю ozo, но в ozo смущает медленное развитие и отсутствие коммитов уже год.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #23

23. Сообщение от dmitigr (ok), 19-Апр-22, 19:44 +1 +/–

Постараюсь добавить поддержку ASIO. Issue по данной задаче -- https://github.com/dmitigr/pgfe/issues/14
По любой проблеме можете смело открывать issue ;-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Аноним (-), 19-Апр-22, 19:58 +/–

Удобство это только одна сторона медали.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

25. Сообщение от Аноним (-), 19-Апр-22, 19:59 +/–

>Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП
Вам так часто нужно наследование?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

26. Сообщение от Аноним (26), 19-Апр-22, 21:20 +/–

> Без классов - не по феншую.
Реализации классов типа DBconnection/dataset поверх чисто сишной libpq получаются очень компактными и простыми. И здесь во многом заслуга сишного API libpq.
Умещался в 2 модуля .cpp/.h: самый большой - меньше 1000 строк, в сумме - около 2000 строк. Ради такой фигни выбирать отдельную либу как-то и не хочется... RAII/подходящий variant/логи,обработку ошибок,исключения и т.д. проще самому добавить по вкусу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

30. Сообщение от adolfus (ok), 23-Апр-22, 02:10 +/–

ООП плохо стыкуется с базами данных. Причем на всех уровнях -- от ISAM, что внизу, до SQL, что над ним. Паридигмы несовместимы. В С++ выручает только то, что это не ОО язык, а язык с некоторыми элементами ООП, которые можно просто отодвинуть в сторону. На бейсике удобнее с базами работать, нежели на любом из ОО языков.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 18-Апр-22, 22:05	+/–
Есть сравнение с libpqxx?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #8, #20

5. Сообщение от Аноним (5), 18-Апр-22, 23:38	–9 +/–
Второй тред этой темы что Постгря УГ. Даже яндекс еда работает на MySQL. Постргря безнадежно отстала в накручивании своих ненужных фич.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #6, #13

6. Сообщение от Аноним (6), 19-Апр-22, 01:13	–7 +/–
Меня в постгре больше всего убило, что нельзя просто взять psql и соединиться с какой-нибудь удаленной постгрей. Версия должна совпадать, иначе она отказывается работать. Версия обязательно не совпадет. На локалхосте у вас одна, на проде или стейдже - другая. В конце концов получается, что нужно звонить по ссш на хост и там локально коннектиться к постгре с помощью psql который с ней заведомо совместим. MySQL между версиями 5.7 и 5.6 серьезно отличается, однако клиент работает между ними без проблем. Куча эндемичных для постгри способов написать запрос, которые надо помнить. Постгре авторитарно замыкает программиста на себя, тогда как мускля покупает его своей простотой и понятностью, которую даже не осознаешь, пока не столкнешься с постгредебилизмом!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #7, #9, #12

7. Сообщение от Заноним (?), 19-Апр-22, 02:50	+1 +/–
Ты какую-то дичь нагнал, psql обычно подключается даже старый клиент к новым серверам, просто warning'и накидывает. А вот pg_dump/pg_restore да, защищают от глупых действий.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

8. Сообщение от Аноним (8), 19-Апр-22, 02:51	+3 +/–
libpq на чистом C очень простая, приятная и удобная в работе вещь! Забудь про биндинги к плюсам (за исключением универсальных либ с возможностью поменять драйвер СУБД), там сложнее и хуже. P.S. Я серьезно, постгрес один из немногих случаев, когда сразу сделано нормально и удобно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #17

9. Сообщение от aaaaa (?), 19-Апр-22, 02:55	+2 +/–
болеешь?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

10. Сообщение от Аноним (10), 19-Апр-22, 03:14	+2 +/–
Когда-то писал свой драйвер Postges для C++. Подключение было неблокирующее по бинарному протоколу с динамической генерацией конвертации из бинарных данных Postgres в переменные C++ и обратно. С помощью шаблонов во время компиляции определялся тип переменной C++, а во время рантайма запрашивались типы полей в базе. Так становилось понятно, какие типы куда конвертировать. Далее генерировались функции преобразования из, например, PG:bigint в C++:int32 для ответов и обратно для запросов. Для этого изначально компилировался объектник с разными преобразованиями и из него в mmaped память копировались тела нужных функций в нужном порядке с релокациями (в результате для преобразования нужно было обратиться к одной большой функции конвертации через указатель - остальное линейный код, т.е. для select bigint, real, varchar в int, float, string генерировалась фукнция преобразования трех переменных из байтового массива, пришедшего от Postgres). Делается через mmap(), запись туда кода, mprotect(m, size, PROT_READ \| PROT_EXEC) и вызов кода по указателю (в общем, все, как в Java/UPX). Забурился на том, что для генерации работы с std::string пришлось разбираться, что делать с исключениями (а там не просто скопировать сишную функцию с релокацией, там еще нужно обеспечить раскрутку стека, если, например, создание строки бросит исключение). P.S. Конвейерная передача запросов (pipeline) имеет жесткое и неприятное ограничение - в случае ошибки в одном запросе все последующие отменяются и это нужно отслеживать.
Ответить \| Правка \| Наверх \| Cообщить модератору

11. Сообщение от aaaaa (?), 19-Апр-22, 04:24	+1 +/–
как в сравнении с yandex/ozo?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #21

12. Сообщение от Аноним (12), 19-Апр-22, 07:49	+/–
> нельзя просто взять psql и соединиться с какой-нибудь удаленной постгрей Ты грибов из яндекс еды (собеседника выше) наелся?!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

13. Сообщение от Аноним (13), 19-Апр-22, 07:51	+/–
Очень толстый вброс.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

14. Сообщение от Аноним (-), 19-Апр-22, 08:11	+3 +/–
Как ни крути, а библиотеки должны быть с сишным интерфейсом.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #15

15. Сообщение от Аноним (15), 19-Апр-22, 10:25	–4 +/–
Прикол в том, что для конечного программиста максимально удобной является обертка в ООП, причем даже визуальное или полу-визуальное. Фиг знает, как это правильно объяснить. Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП. Оно естественное чисто потому, что так тупо будет меньше кода. А количество кода = трудозатраты программиста. Так зачем каждый раз изобретать велосипед? Именно поэтому мне нравится идея Delphi/Lazarus и очень жаль, что для C++ нет свободной альтернативы C++ Builder.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14 Ответы: #16, #19, #24, #25

16. Сообщение от Аноним (16), 19-Апр-22, 10:32	+/–
Для этого есть Qt. Но есть нюанс :]
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

17. Сообщение от Аноним (17), 19-Апр-22, 12:18	+/–
>Забудь про биндинги к плюсам Без классов - не по феншую.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #26, #30

19. Сообщение от Аноним (12), 19-Апр-22, 13:57	+/–
> максимально удобной является обертка в ООП Ты путаешь язык и парадигму. ООПить можно хоть на ассемблере.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

20. Сообщение от dmitigr (ok), 19-Апр-22, 17:20	+4 +/–
Если вкратце, то Pgfe предоставляет гораздо более богатый набор возможностей, современней и является отечественным ПО ;-)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

21. Сообщение от dmitigr (ok), 19-Апр-22, 17:27	+1 +/–
Гораздо больше возможностей. В версии 2.1 будет добавлен API асинхронного ввода/вывода на базе обратных вызовов, что позволит использовать Pgfe в приложениях с циклом событий на базе разных его реализаций (в первую очередь, на базе libuv, но, вероятно, будет и поддержка ASIO, как в Ozo).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #22

22. Сообщение от aaaaa (?), 19-Апр-22, 18:42	+/–
Дмитрий, приветствую! Спасибо за обратную связь! Поддержка asio была бы замечательным дополнением. Я в своем web frameworkе использую boost.asio + boost.beast и в качестве backendа для pgsql ковыряю ozo, но в ozo смущает медленное развитие и отсутствие коммитов уже год.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #23

23. Сообщение от dmitigr (ok), 19-Апр-22, 19:44	+1 +/–
Постараюсь добавить поддержку ASIO. Issue по данной задаче -- https://github.com/dmitigr/pgfe/issues/14 По любой проблеме можете смело открывать issue ;-)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22

24. Сообщение от Аноним (-), 19-Апр-22, 19:58	+/–
Удобство это только одна сторона медали.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

25. Сообщение от Аноним (-), 19-Апр-22, 19:59	+/–
>Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП Вам так часто нужно наследование?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

26. Сообщение от Аноним (26), 19-Апр-22, 21:20	+/–
> Без классов - не по феншую. Реализации классов типа DBconnection/dataset поверх чисто сишной libpq получаются очень компактными и простыми. И здесь во многом заслуга сишного API libpq. Умещался в 2 модуля .cpp/.h: самый большой - меньше 1000 строк, в сумме - около 2000 строк. Ради такой фигни выбирать отдельную либу как-то и не хочется... RAII/подходящий variant/логи,обработку ошибок,исключения и т.д. проще самому добавить по вкусу.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

30. Сообщение от adolfus (ok), 23-Апр-22, 02:10	+/–
ООП плохо стыкуется с базами данных. Причем на всех уровнях -- от ISAM, что внизу, до SQL, что над ним. Паридигмы несовместимы. В С++ выручает только то, что это не ОО язык, а язык с некоторыми элементами ООП, которые можно просто отодвинуть в сторону. На бейсике удобнее с базами работать, нежели на любом из ОО языков.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17