Concernant le FOSDEM, il s'agit d'un événement très orienté développeurs. Je vous conseille donc d'orienter votre conférence/proposition pour qu'elle soit intéressante pour des développeurs.
]]>Super travail. Merci beaucoup !
]]>http://olivierch.github.com/openBarter/
Cdt.
]]>Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.A+
Il est dommage que PostGreSQL n'implémente d'ailleurs pas toute la norme, car par exemple DEPTH FIRST est prévu dans la norme SQL. En sus, sachez que toutes les requêtes dans un SGBDR sont faites en mémoire, avec en sus l'optimisation, ce qui conduit dans les cas de fort volume à des performances au dessus de ce que vous feriez en codage C.
Il est aussi dommage que PostGreSQL contrairement à SQL Server ou Oracle ne soit pas capable de parallélisé une seule et même requête, car là encore les performances du SGBDR deviennent sans communes mesure à ce que l'on peut faire en C, à moins d'avoir prévu de lancer des threads en //
A +
]]>L'extension est portée sur la version 9.1 . Je vais prendre connaissance de CREATE EXTENSION, et suivre tes recommandations.
Merci pour ces conseils.
]]>Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.A+
Bonjour,
très intéressant.
Pour le partie publication/communication, je vous suggère d'en faire une extension utilisable avec CREATE EXTENSION (9.1), puis de la publier sur PGXN. Vous pouvez l'annoncer sur la mailling list pgsql-announce, David Fetter se charge de la news hebdomadaire et vous pouvez aussi lui envoyer un mail en direct (cf archive postgresql pour avoir son mail). Vous pouvez aussi faire une annonce sur la mailling pgsql-fr-generale. (cf postgresql.org pour consulter/ss'abonner)
Utiliser le moteur PostgreSQL ne veut pas dire recoder votre extension en plpgsql, le C est très bien. La question qui demeure est qu'est-ce que berkely DB apporte que n'apporte pas déjà postgresql dans votre contexte. Je n'ai pas lu votre code mais je suppose qu'il suffit de changer le 'backend' berkeleyDB par postgresql, et voilà, non ?
]]>A +
]]>A+
]]>