Опыт работы с интерфейсом IBPP для базы данных Firebird

Question

Я хотел бы спросить парней с опытом работы в Firebird и IBPP (особенно в последних). Я нашел много положительных сообщений о Firebird, но у меня возникла проблема с выбором IBPP. Сам интерфейс прост и понятен, но кажется, что в проекте мало что происходит (возможно, потому что он очень стабилен).

• Вы бы порекомендовали IBPP для производственной среды?
• Это потокобезопасно?
• Любые известные ошибки?

Спасибо.

Answer 1

IBPP очень стабильный, и я бы рекомендовал его для производства. То есть, если вы собираетесь использовать его для обычных приложений.

Если вы хотите создать инструмент администратора или что-то подобное, будьте готовы пойти внутрь и запачкать руки, так как некоторые из более новых функций (например, Firebird 2.5), которые не являются SQL, но улучшения API не поддерживаются. Например, отсутствует слой, который предоставит новый API-интерфейс трассировки.

Во всяком случае, давай, и я использую это. У меня есть куча приложений IBPP в производстве в течение многих лет, и, как писал Дуглас, FlameRobin использует IBPP, и он работает безупречно (по крайней мере, в отношении уровня DB).

Единственное, о чем следует быть осторожным, - это ЧИСЛОВЫЕ поля, которые внутренне хранятся как целочисленные + масштабные в Firebird. IBPP выставляет их через C / C ++ «double», но также через 16/32/64-битное целое число. Поэтому будьте очень осторожны при получении таких значений, так как вы не получите предупреждения. Например, если у вас есть поле DECIMAL (18,2) со значением 254,00, и вы случайно прочитали его в целое число, вы получите 25400, а не 254. Убедитесь, что вы либо прочитали их как двойные, либо масштабировали себя позже. Это полезно, потому что вы можете безопасно преобразовать 25400 в строку, а затем добавить десятичную точку, чтобы не потерять точность с двойной точностью (все зависит от типа вашего приложения и количества цифр, конечно).

Answer 2

Помимо очков Милан упомянул:

• В настоящее время нет возможности использовать более одной клиентской библиотеки при подключении к различным базам данных или даже указать, какая клиентская библиотека будет использоваться. Существует определенная жестко заданная последовательность местоположений клиентских библиотек, и первый найденный будет использоваться для всех соединений. Версия IBPP, изменяющая это, намекалась очень давно, но еще не пришла. SVN trunk содержит некоторый код для решения этой проблемы, но я бы сказал, что это самое большее альфа-качество.
  И все это верно только для Windows, поскольку на всех других платформах клиентская библиотека Firebird все равно не загружается во время выполнения.

• Библиотека не является поточно-ориентированной. По большей части это не имеет значения, так как вы должны в любом случае позволить каждому потоку иметь свое собственное соединение, транзакцию и другие разные объекты. Но IBPP использует собственную реализацию интеллектуального указателя, которая не является ни полностью исключительной, ни поточно-ориентированной. Тем не менее, до тех пор, пока вы инициализируете библиотеку из основного потока (до создания какого-либо другого потока) и создаете и уничтожаете объекты IBPP в одном потоке (так что абсолютно нет совместного использования объектов с другими потоками!), Используя IBPP в нескольких потоках, должно работать хорошо.

• Если вы можете жить с указанными выше пунктами (они могут вообще не иметь для вас значения), это, безусловно, готово для производственного использования. Вы всегда можете изменить то, с чем столкнулись, как мы это делали и для FlameRobin.

Answer 3

Я не могу сказать по опыту, потому что я никогда не использовал IBPP.
Но, видимо, он используется проектом Flamerobin, поэтому я уверен, что он будет «достаточно стабильным».