Опубликован первый стабильный выпуск Pgfe 2 (PostGres FrontEnd), продвинутого и многофункционального драйвера (клиентский API) для PostgreSQL, написанного на языке C++ и упрощающего работу с PostgreSQL в проектах на C++. Код проекта распространяется под лицензией Apache 2.0. Для сборки требуется компилятор с поддержкой стандарта C++17...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57039
Есть сравнение с libpqxx?
libpq на чистом C очень простая, приятная и удобная в работе вещь! Забудь про биндинги к плюсам (за исключением универсальных либ с возможностью поменять драйвер СУБД), там сложнее и хуже.P.S. Я серьезно, постгрес один из немногих случаев, когда сразу сделано нормально и удобно.
>Забудь про биндинги к плюсамБез классов - не по феншую.
> Без классов - не по феншую.Реализации классов типа DBconnection/dataset поверх чисто сишной libpq получаются очень компактными и простыми. И здесь во многом заслуга сишного API libpq.
Умещался в 2 модуля .cpp/.h: самый большой - меньше 1000 строк, в сумме - около 2000 строк. Ради такой фигни выбирать отдельную либу как-то и не хочется... RAII/подходящий variant/логи,обработку ошибок,исключения и т.д. проще самому добавить по вкусу.
ООП плохо стыкуется с базами данных. Причем на всех уровнях -- от ISAM, что внизу, до SQL, что над ним. Паридигмы несовместимы. В С++ выручает только то, что это не ОО язык, а язык с некоторыми элементами ООП, которые можно просто отодвинуть в сторону. На бейсике удобнее с базами работать, нежели на любом из ОО языков.
Если вкратце, то Pgfe предоставляет гораздо более богатый набор возможностей, современней и является отечественным ПО ;-)
Второй тред этой темы что Постгря УГ. Даже яндекс еда работает на MySQL. Постргря безнадежно отстала в накручивании своих ненужных фич.
Меня в постгре больше всего убило, что нельзя просто взять psql и соединиться с какой-нибудь удаленной постгрей. Версия должна совпадать, иначе она отказывается работать. Версия обязательно не совпадет. На локалхосте у вас одна, на проде или стейдже - другая. В конце концов получается, что нужно звонить по ссш на хост и там локально коннектиться к постгре с помощью psql который с ней заведомо совместим. MySQL между версиями 5.7 и 5.6 серьезно отличается, однако клиент работает между ними без проблем.Куча эндемичных для постгри способов написать запрос, которые надо помнить. Постгре авторитарно замыкает программиста на себя, тогда как мускля покупает его своей простотой и понятностью, которую даже не осознаешь, пока не столкнешься с постгредебилизмом!
Ты какую-то дичь нагнал, psql обычно подключается даже старый клиент к новым серверам, просто warning'и накидывает.А вот pg_dump/pg_restore да, защищают от глупых действий.
болеешь?
> нельзя просто взять psql и соединиться с какой-нибудь удаленной постгрейТы грибов из яндекс еды (собеседника выше) наелся?!
Очень толстый вброс.
Когда-то писал свой драйвер 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) имеет жесткое и неприятное ограничение - в случае ошибки в одном запросе все последующие отменяются и это нужно отслеживать.
как в сравнении с yandex/ozo?
Гораздо больше возможностей. В версии 2.1 будет добавлен API асинхронного ввода/вывода на базе обратных вызовов, что позволит использовать Pgfe в приложениях с циклом событий на базе разных его реализаций (в первую очередь, на базе libuv, но, вероятно, будет и поддержка ASIO, как в Ozo).
Дмитрий, приветствую! Спасибо за обратную связь!
Поддержка asio была бы замечательным дополнением.
Я в своем web frameworkе использую boost.asio + boost.beast и в качестве backendа для pgsql ковыряю ozo, но в ozo смущает медленное развитие и отсутствие коммитов уже год.
Постараюсь добавить поддержку ASIO. Issue по данной задаче -- https://github.com/dmitigr/pgfe/issues/14По любой проблеме можете смело открывать issue ;-)
Как ни крути, а библиотеки должны быть с сишным интерфейсом.
Прикол в том, что для конечного программиста максимально удобной является обертка в ООП, причем даже визуальное или полу-визуальное. Фиг знает, как это правильно объяснить. Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООП. Оно естественное чисто потому, что так тупо будет меньше кода. А количество кода = трудозатраты программиста. Так зачем каждый раз изобретать велосипед? Именно поэтому мне нравится идея Delphi/Lazarus и очень жаль, что для C++ нет свободной альтернативы C++ Builder.
Для этого есть Qt. Но есть нюанс :]
> максимально удобной является обертка в ООПТы путаешь язык и парадигму. ООПить можно хоть на ассемблере.
Удобство это только одна сторона медали.
>Но мне вот самому не удобно работать со всеми этими низкоуровневыми интерфейсами, так что возникает естественное желание обернуть все в ООПВам так часто нужно наследование?