Как стать автором
Обновить

Комментарии 18

Здравствуйте!

Разве необходимо что-то делать с std::auto_ptr? Насколько я могу судить, std::auto_ptr используется только в случае, если не доступен std::unique_ptr, т.е. при сборке в режиме C++98/03. Или я что-то упускаю?

P.S. Можно не открывать Visual Studio для сборки:

cmake --build . --config Release


(вместо Release можно использовать Debug, RelWithDegInfo, MinSizeRel или другой конфигурации сборки. Мелочь, конечно, но из терминала использовать удобнее получается.
Добрый вечер.

Да вы правы, если пользовать ветку 4.*, но ссылку я дал на 3.2.3, а там такого нет ))
Я сделаю правку в тексте, спасибо!
Прошу простит невнимательность — пропустил ссылку на архив с исходными кодами, увидел только в конце ссылку на репозиторий.
Если хотите что-то более универсальное, используйте NanoDBC. NanoDBC использует ODBC или unixODBC в качестве backend, что позволяет использовать многочисленные драйверы ODBC в С++.
SOCI тоже поддерживает: ODBC with specific database driver, текст поправил, спасибо за замечание.
А что самое интересное, у NanODBC и SOCI один автор.
Я имел в виду mloskot'а.

Вообще, авторы библиотеки в периодически всплывающей активности на github-е рекомендуют использовать ветку 4.x (для нее нет релиза, нужно ставить прямо с гитхаба).


Ну и я бы с опаской относился к этой библиотеке — она уже давно не развивается, а на гитхабе висит незакрытыми 86 задач. Так что если возникнут какие-то проблемы, вы будете с ними один на один.


Да, и например, нормальной поддержки LOB-ов там нет, весь LOB читается за раз в строчку (как минимум в оракловском бекенде).

По поводу версии сделал замечание в тексте статьи — качать свежие сырцы.


Незакрытые задачи по большей части всплывают из-за желания юзеров юзать из коробки
очень специфичные вещи.


А для LOB'ов юзайте стандартный API soci::blob:


интерфейс soci::blob
class SOCI_DECL blob
{
public:
    explicit blob(session & s);
    ~blob();

    std::size_t get_len();

    // offset is backend-specific
    std::size_t read(std::size_t offset, char * buf, std::size_t toRead);

    // offset starts from 0
    std::size_t read_from_start(char * buf, std::size_t toRead,
        std::size_t offset = 0);

    // offset is backend-specific
    std::size_t write(std::size_t offset, char const * buf,
        std::size_t toWrite);

    // offset starts from 0
    std::size_t write_from_start(const char * buf, std::size_t toWrite,
        std::size_t offset = 0);

    std::size_t append(char const * buf, std::size_t toWrite);

    void trim(std::size_t newLen);

    details::blob_backend * get_backend() { return backEnd_; }

private:
    details::blob_backend * backEnd_;
};
Ну я бы не был столь категоричен. В edba 143 коммита, последний был 2.5 года назад, cppdb дальше cppcms не забралась и, видимо, поэтому была заброшена.

У soci 2450 коммитов, последний был пару месяцев назад, сам проект уже черти когда назад начал писаться. На самом деле, продукт зрелый.

Да зрелый, более точное определение для проекта с датой последнего релиза 2015. Как и парочка упомянутых выше. Вот еще один зрелый проект для коллекции: https://github.com/pmed/sqlitepp :)


По моему небольшому опыту, сама идея встраивания SQL-подобного кода в С++ программу в конечном итоге заканчивается спуском к деталям реализации конкретной БД и вызову конкретных функций коннектора этой БД.

По моему небольшому опыту, сама идея встраивания SQL-подобного кода в С++ программу в конечном итоге заканчивается спуском к деталям реализации конкретной БД и вызову конкретных функций коннектора этой БД.

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


Напишите статью "я против всяких ORM библиотек, я за чистый SQL", киньте ссылку, и мы будем в курсе раз и навсегда ))


PS: советую перепрочитать статью, я её переработал, возможно в том виде в каком вы её читали, не дала вам ясных представлений...

Делать и использовать нужно то, что подходит под требования проекта. На мой взгляд, edba выглядит лучше в качестве универсальной библиотеки. В ней, по крайней мере используется C++11 без ручного управления памятью и deprecated
auto_ptr.


Статей про плюсы/минусы ORM и без меня уже написано за последние лет 20 много, так что я, пожалуй, не буду увеличивать энтропию.


Я глянул на код вашей статьи. В db_pool возможно двойное освобождение памяти — сырой указатель и отсутствие конструктора копирования гарантируют это.


В user_info рукопашный код для перегона


std::vector<int> friends; // айдишники друзей

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


В test.cxx в строках


 // нам нужно для каждого бэкенда, указать правильный тип авто-счётчика для поля id
      if (sql.get_backend_name() == "postgresql") query_str += " SERIAL ";
      else if (sql.get_backend_name() == "mysql") query_str += " INT AUTO_INCREMENT ";

вы показываете суть универсального доступа к БД — и вынуждены бороться с различиями диалектов SQL.

Делать и использовать нужно то, что подходит под требования проекта.

Вот именно !


А по всем остальным пунктам, касательно моего быдлокодерства (не заморочился с потоко-безопасностью, сделал хранение массива чисел в строке потому что в SOCI нет этой поддержки, борюсь с диалектами SQL) отвечу:


всё что я посчитал нужным осветить в данной статье — я осветил,
если вам не нравится как я подготовил этот tutorial — ну на вкус и цвет как говорится ))

Название библеотеки улыбнуло)

ЛОЛ...


Никогда не замечал, всегда читал Соци ))


Может поэтому она не популярна в РФ ?..

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории