Merci pour tout !
]]>J'ai bien tenté de la compiler avec MinGW, mais après avoir exécuté le configure, lorsque j'essaye de lancer un "make", il me dit qu'il n'y a rien à faire pour "all" ni pour "all-am".
Par acquis de conscience j'ai essayé et je n'ai pas ce problème:
(pré-requis: configure && make && make install de postgresql avec mingw):
Configuration:
$ cd /c/src/pgstream-1.0
$ ./configure --with-pgsql-includes=/usr/local/pgsql/include --with-pgsql-libs=/usr/local/pgsql/lib/
....la partie finale du résultat...:
checking whether to build static libraries... yes
creating libtool
which: pg_config: unknown command
configure: WARNING: Couldn't find pg_config in PATH.
checking libpq-fe.h usability... yes
checking libpq-fe.h presence... yes
checking for libpq-fe.h... yes
checking for PQexec in -lpq... yes
checking for PQexecParams in -lpq... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: executing depfiles commands
Compilation:
$ make
Making all in src
make[1]: Entering directory `/c/src/pgstream-1.0/src'
source='pgstream.cpp' object='pgstream.lo' libtool=yes \
depfile='.deps/pgstream.Plo' tmpdepfile='.deps/pgstream.TPlo' \
depmode=gcc3 /bin/sh ../depcomp \
/bin/sh ../libtool --mode=compile g++ -DPACKAGE_NAME=\"pgstream\" -DPACK
AGE_TARNAME=\"pgstream\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"pgstream\
1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pgstream\" -DVERSION=\"1.0\" -DSTDC_H
EADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRIN
G_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_LIBPQ_FE_H=1 -I. -I. -I/usr/local/pgsql/include -
g -O2 -c -o pgstream.lo `test -f 'pgstream.cpp' || echo './'`pgstream.cpp
mkdir .libs
g++ -DPACKAGE_NAME=\"pgstream\" -DPACKAGE_TARNAME=\"pgstream\" -DPACKAGE_VERSION
=\"1.0\" "-DPACKAGE_STRING=\"pgstream 1.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=
\"pgstream\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_
STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=
1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBPQ_FE_H=1 -I
. -I. -I/usr/local/pgsql/include -g -O2 -c pgstream.cpp -MT pgstream.lo -MD -MP
-MF .deps/pgstream.TPlo -DDLL_EXPORT -DPIC -o .libs/pgstream.lo
g++ -DPACKAGE_NAME=\"pgstream\" -DPACKAGE_TARNAME=\"pgstream\" -DPACKAGE_VERSION
=\"1.0\" "-DPACKAGE_STRING=\"pgstream 1.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=
\"pgstream\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_
STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=
1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBPQ_FE_H=1 -I
. -I. -I/usr/local/pgsql/include -g -O2 -c pgstream.cpp -MT pgstream.lo -MD -MP
-MF .deps/pgstream.TPlo -o pgstream.o >/dev/null 2>&1
mv -f .libs/pgstream.lo pgstream.lo
/bin/sh ../libtool --mode=link g++ -g -O2 -o libpgstream.la -rpath /usr/local
/lib -version-info 1:0:0 pgstream.lo -lpq -L/usr/local/pgsql/lib/
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared
libraries
rm -fr .libs/libpgstream.la .libs/libpgstream.* .libs/libpgstream.*
ar cru .libs/libpgstream.a pgstream.o
ranlib .libs/libpgstream.a
creating libpgstream.la
(cd .libs && rm -f libpgstream.la && ln -s ../libpgstream.la libpgstream.la)
make[1]: Leaving directory `/c/src/pgstream-1.0/src'
make[1]: Entering directory `/c/src/pgstream-1.0'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/c/src/pgstream-1.0'
Ceci étant, le format .a/.lib pour un simple couple de fichiers (.cpp,.h) n'est pas indispensable.
]]>Pour l'allocation dynamique de tableau, à mon avis la meillleure solution est d'utiliser alloca() qui est dispo à la fois en glibc (gnu) et en Visual C++. Il faut simplement si je me rappelle bien éviter de lever une exception C++ avant la fin de la fonction appelante.
Pour la création de base en mode non connecté, c'est impossible avec postgresql, la solution la plus simple consiste à se connecter à la base template1 (pré-créée automatiquement par initdb) pour exécuter le CREATE DATABASE.
]]>Le premier concerne "snprintf", mais même en incluant le header qui va bien (cstdio), le compilateur semble ne pas trouver cette fonction. En revanche, il trouve "_snprintf" qui est une fonction disponible dans stdio.h, que tu as déjà inclut. Est-ce que ces 2 fonctions ont vraiment le même comportement ?
Le deuxième est à propos de l'allocation d'un tableau avec une taille dynamique. D'après ce que j'ai compris, cette pratique est supportée depuis la norme C99 du C, mais le compilateur de Visual Studio ne semble pas l'autoriser pour une raison inconnue. J'ai donc dû modifier légèrement le code, mais j'aurais besoin de tes conseils puisque j'ai forcément besoin d'une taille "max" qui puisse être utilisée à la place de "m_vars.size()" et je n'ai absolument aucune idée de ce que ça peut être.
Autre petite question qui n'a presque rien à voir, j'aimerais être capable de créer une base de données à partir de mon code, or, pour tout ce qui concerne la communication avec celle-ci, il faut, au préalable, s'être connecté à une base. Comment faire dans ce cas ?
Merci encore et bonne journée !
]]>Je viens à peine de réussir à compiler la libpqxx et je commence à hésiter à l'utiliser finalement plutôt que celle que tu as développées, car elle m'a l'air très bien faite.
Comme j'ai encore un peu de mal à me décider (et que je m'étais promis hier de rester sur libpqxx quoiqu'il arrive maintenant ), j'aurais juste voulu savoir ce qu'il te restait encore des à développer pour pgstream (j'ai cru comprendre qu'elle était encore en version bêta).
]]>Sinon, t'as surcouche semble être intéressante, mais j'ai l'impression que tout comme libpqxx, tu ne proposes rien en ce qui concerne sa compilation sur des systèmes Windows
J'ai sous le coude un mail avec un patch d'un utilisateur pour VS2010 qu'il faudrait que j'intègre.
Je crois qu'il y a juste une allocation dynamique de tableau dans la pile (=extension gcc) qui nécessite un remplacement de code, le reste étant surtout du préprocesseur. Rien de bien méchant.
Pour ce qui est de la compilation à part, la manière la plus simple de l'exploiter est de copier le .h et .cpp dans son propre projet sans même chercher à en faire une lib, ça va tout à fait avec le côté basique et léger de la surcouche.
Est-ce que tu peux m'en dire plus sur les choix de conception de libpqxx que tu n'as pas aimé ? (mis à part le défaut cité plus haut)
Ok, voici quelques éléments de réponse:
Un inconvénient concret est qu'on ne peut pas exécuter des commandes sql sans instancier d'abord une transaction, alors que postgresql lui-même ne l'impose pas (non seulement il ne l'impose pas mais dans de rares comme CREATE DATABASE, il l'interdit. A ce jour il me semble qu'il n'y a tjrs pas de moyen de faire un create database avec libpqxx).
En plus le design pattern suggéré des functors pour les transactions me parait trop loin de la logique classique d'encapsulation, et sert surtout à "résoudre" un pb (la perte de connexion), qui à mon avis est hors sujet.
La lib ne gère pas du tout le format binaire. L'intérêt du binaire est discutable pour le tout venant, mais pour les champs bytea de taille significative, c'est dommage.
D'une manière générale, le niveau d'abstraction de l'API me parait trop élevé là où ça ne m'intéresse pas vraiment et pas assez là où ça m'intéresserait.
Trop: parce que quand on connait déjà les idiomes postgresql et qu'on sait à quoi on veut arriver au niveau SQL, on se retrouve à décortiquer l'API de haut en bas pour trouver derrière quelle classe c'est caché et à quel niveau de la hiérarchie il faut opérer. Parfois c'est dur à comprendre: pour les prepared statements par exemple, la méthode pour typer les paramètres m'a paru incompréhensible, et aucun exemple ni dans la doc ni dans le tutoriel.
En revanche, peu d'abstraction pour les manipulations de données échangées entre client et serveur et la gestion de type. On utilise esc(), to_string(), from_string() pour encoder/décoder, et là on se croirait presque en C. Cette partie-là me parait décevante parce qu'on peut faire mieux en C++. Rien non plus pour gérer les tableaux ou les types composites ni en entrée ni en sortie.
]]>Est-ce que tu peux m'en dire plus sur les choix de conception de libpqxx que tu n'as pas aimé ? (mis à part le défaut cité plus haut)
Sinon, t'as surcouche semble être intéressante, mais j'ai l'impression que tout comme libpqxx, tu ne proposes rien en ce qui concerne sa compilation sur des systèmes Windows, et j'ai malheureusement besoin d'une lib qui soit multiplate-forme. J'ai bien tenté de la compiler avec MinGW, mais après avoir exécuté le configure, lorsque j'essaye de lancer un "make", il me dit qu'il n'y a rien à faire pour "all" ni pour "all-am".
Quant à libpqtypes, ça reste du C, mais je vais y jeter un oeil !
Merci encore !
]]>En principe, on peut tout aussi bien utiliser la puissance de libpq avec libpqxx puisqu'il s'agit, pour moi, d'une simple surcouche permettant l'utilisation de la syntaxe propre au C++. libpq est donc nécessaire pour que libpqxx puisse fonctionner et donc si jamais des fonctionnalités offertes par libpq ne sont pas exploité avec libpqxx, on peut toujours utiliser la lib de base !
A condition de le faire dans une connexion à part, ce qui en limite beaucoup l'intérêt, Car il y a une étanchéité explicite entre libpqxx et libpq.
Extrait de la FAQ: http://pqxx.org/development/libpqxx/wiki/FaqFeatures
For my program I need to access some C-level libpq structure that libpqxx hides from me. Can you add a member function that lets me do this?
Generally, no. If you require support for specific high-level functionality, the better solution is usually to build it into the abstraction layer rather than to break the abstraction layer open like this.
Also, the isolation that the abstraction layer provides allows libpqxx to do things like automatic connection recovery. Such things can be impossible if the library does not have full and unique control over the underlying C-level structures, or in other cases they might lead to subtle and complex bugs in your program.
Personnellement, ayant besoin de C++ et peu emballé par l'API de libpqxx et certains de ses choix de conception, j'ai choisi il y a longtemps de faire ma propre surcouche ( http://manitou-mail.org/pgstream/overview.html ) qui permet de mélanger C et C++ , mais surtout avec une API plutôt du style d'OTL pour oracle ( http://otl.sourceforge.net ) dont l'élégance m'avait impressionné.
Et aujourd'hui pour PG il y a aussi libpqtypes en C ( http://libpqtypes.esilo.com/ ) qui est à considérer pour se simplifier le code.
]]>Malheureusement, et pour une raison que j'ignore, il ne connait pas la commande "vcbuild", ce qui l'empêche de construire quoique ce soit...
Pourtant, j'ai bien pris soin de lancer le script build.bat avec l'environnement de Visual Studio 2011 (en prenant l'invite de commande fournie par Visual Studio).
J'ai quand même chercher pour voir où pouvait se trouver un éventuel binaire nommé "vcbuild.exe" dans les dossiers d'installation de Visual Studio, afin de l'ajouter au PATH, mais je n'ai malheureusement rien trouvé. Pourtant, il devrait être présent puisque j'ai installé Visual Studio, non ?
Merci encore.
]]>