Expérience avec l'interface IBPP pour la base de données Firebird

Question

Je voudrais demander aux gars ayant une expérience dans Firebird et IBPP (en particulier ce dernier). J'ai trouvé beaucoup de messages positifs sur Firebird mais j'ai un problème pour décider de l'IBPP. L'interface elle-même est propre et simple mais il semble que le projet n'a pas beaucoup d'activité en cours (peut-être parce que c'est très stable).

• Recommanderiez-vous IBPP pour l'environnement de production?
• Est-ce thread-safe?
• Des bogues connus?

Merci.

Answer 1

En plus des points de Milan mentionnés:

• Il n'y a actuellement aucun moyen d'utiliser plus d'une bibliothèque client lors de la connexion à différentes bases de données, ou même de spécifier quelle bibliothèque client sera utilisé. Il y a une certaine séquence codée en dur des emplacements de bibliothèque client qui sont sondés, et le premier qui est trouvé sera utilisé pour toutes les connexions. Une version de l'IBPP modifiant cela a été suggérée depuis très longtemps, mais n'est pas encore arrivée. SVN trunk contient du code pour traiter cela, mais je dirais que c'est la qualité alpha au maximum.
  Et tout cela est vrai pour Windows uniquement, car sur toutes les autres plates-formes, la bibliothèque du client Firebird n'est pas chargée à l'exécution de toute façon.

• La bibliothèque n'est pas adaptée aux threads. Cela n'a pas d'importance pour la plupart, car vous devriez laisser chaque thread avoir sa propre connexion, transaction et autres objets assortis de toute façon. Mais IBPP utilise sa propre implémentation de pointeur intelligent, qui n'est ni complètement sûre pour les exceptions, ni sûre pour les threads.Pourtant, tant que vous initialisez la bibliothèque à partir du thread principal (avant que tout autre thread est créé) et créer et détruire des objets IBPP dans le même thread (donc absolument pas de partage d'objets avec d'autres threads!) IBPP dans plusieurs threads devrait fonctionner bien.

• Si vous pouvez vivre avec les points ci-dessus (ils peuvent ne pas vous importer, du tout), il est certainement prêt pour une utilisation en production. Vous pouvez toujours changer les choses que vous rencontrez, comme nous l'avons fait pour FlameRobin aussi.

Answer 2

Je ne peux pas vraiment dire d'expérience parce que je n'ai jamais utilisé IBPP.
Mais apparemment, il est utilisé par le projet flamerobin, donc je crois qu'il est «assez stable».

Answer 3

L'IBPP est très stable et je le recommande pour la production. Autrement dit, si vous allez l'utiliser pour des applications régulières. Si vous voulez construire un outil d'administration ou quelque chose de similaire, préparez-vous à rentrer dedans et à vous salir les mains car certaines des nouvelles fonctionnalités (Firebird 2.5) ne sont pas SQL mais les améliorations de l'API ne sont pas supportées. Par exemple, il manque une couche qui exposerait la nouvelle API de trace.

Quoi qu'il en soit, allez-y et je l'utilise. J'ai un tas d'applications IBPP en production depuis des années, et, comme Douglas l'a écrit, FlameRobin utilise IBPP et cela fonctionne parfaitement (au moins en ce qui concerne la couche DB). La seule chose dont il faut se méfier est les champs NUMERIC, qui sont stockés en interne sous forme d'entier + échelle dans Firebird. IBPP les expose via C/C++ "double", mais aussi via un entier 16/32/64bit. Soyez donc très prudent lorsque vous récupérez de telles valeurs, car vous n'obtiendrez aucun avertissement. Par exemple, si vous avez un champ DECIMAL (18,2) avec une valeur de 254,00, et que vous avez accidentellement lu cela dans un entier, vous obtiendrez 25400, pas 254. Assurez-vous de les lire en double ou de les redimensionner plus tard. Ceci est utile car vous pouvez convertir en toute sécurité 25400 en chaîne puis ajouter un point décimal, de sorte que vous ne perdiez pas de précision en double (tout dépend du type de votre application et des chiffres qui comptent, bien sûr).