![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Необъяснимые вещи необъяснимы
В firebird-devel обсуждают новый ABI/API для Firebird.
Вот этот товарищ: http://en.wikipedia.org/wiki/Jim_Starkey навязывает всем свое видение, на тему использования чего-то JDBC-подобного на C++ в качестве базового клиентского API. Остальные кто в лес, кто по дрова - предлагают генерировать API из IDL, использовать plain C апи, кое-кто вспоминает что на улице 2014 год и вообще не помешало бы JSON-апи уже сделать, ссылаются на оракловский OCI и TDS от mssql и прочую чернягу.
Еще один камень преткновения - использование виртуальных функций для чтения значений полей vs чтение напрямую значений из буфера, который прислал сервер при фетче.
По-моему, они все упоролись. Генерировать API хорошая идея, но не из оккультного IDL же.
Впрочем, тут изначально все плохо, т.к. БД по самой своей сути - это динамическая типизация, с вычитыванием схем и результатов парсинга запросов и в конечном итоге оно всегда сводится к мерзости вида "скрестим динамическую типизацию с языками со статической недотипизацией вроде С".
Вот этот товарищ: http://en.wikipedia.org/wiki/Jim_Starkey навязывает всем свое видение, на тему использования чего-то JDBC-подобного на C++ в качестве базового клиентского API. Остальные кто в лес, кто по дрова - предлагают генерировать API из IDL, использовать plain C апи, кое-кто вспоминает что на улице 2014 год и вообще не помешало бы JSON-апи уже сделать, ссылаются на оракловский OCI и TDS от mssql и прочую чернягу.
Еще один камень преткновения - использование виртуальных функций для чтения значений полей vs чтение напрямую значений из буфера, который прислал сервер при фетче.
По-моему, они все упоролись. Генерировать API хорошая идея, но не из оккультного IDL же.
Впрочем, тут изначально все плохо, т.к. БД по самой своей сути - это динамическая типизация, с вычитыванием схем и результатов парсинга запросов и в конечном итоге оно всегда сводится к мерзости вида "скрестим динамическую типизацию с языками со статической недотипизацией вроде С".
no subject
А делать автоинкрементное поле через триггер - это зачем?
Видимо за давностью лет я не помню уже, но разве там не генератор цеплялся точно так же как у PostgreSQL и Oracle?
Но да. Эту РСУБД в России знают исключительно благодаря Borland :)
no subject
Я почти из-за этого делал кодогенерацию SQL, собственно - очень много разницы в разных СУБД именно в плане "сгенерить автоинкремент" и "получить значение автоинкрементного поля".