PoPy et PygreSQL s'unissent pour le meilleur

Posté par . Modéré par Nÿco.
Tags : aucun
0
7
juil.
2003
Python
Les développeurs de PoPy et de PyGreSQL, les 2 premiers pilotes Python pour le SGBDR Postgresql, sont heureux de vous annoncer qu'ils ont décidé d'unir les deux projets pour fournir un nouveau produit plus puissant.
  • # Re: PoPy et PygreSQL s'unissent pour le meilleur

    Posté par (page perso) . Évalué à 4.

    Une chance & merci bien à eux pour que, désormais, nous n'ayons plus ce dilem !

    Bye & bonne fusion,

    Willou.
    • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

      Posté par . Évalué à 6.

      C'est clair, plus besoin de peser le pour et le contre (*)

      Autant je suis pour la coexistence de Gnome/KDE (par exemple), autant je pense que pour un backend, il n'y a pas besoin de se perdre dans 10 implémentations. Sauf si la seule solution existante est vraiment mauvaise mais ce n'est pas le cas ici, donc autant qu'ils mettent leurs talents en commun.

      en tant que développeur Zope je les remercie, même si je n'utilise jamais de SGBDR dans mes projets, on ne sait jamais :)

      * : enfin dans le futur, quand ça sera concret.
      • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

        Posté par . Évalué à -2.

        Tu fais quoi sans SGBDR ?
        Tes données, tu les enregistres dans des fichiers txt ?
        • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

          Posté par . Évalué à 5.

          mouarf, c'est une blague ? Y'a pas que les SGBDR dans la vie !

          Je travaille avec la ZODB, une base de données objet et hiérarchique. En clair, mes instances sont persistantes.

          Certes ce n'est pas applicable partout et ça ne remplace pas toujours mais dans mon cas (gestion documentaire) ça le fait bien !
          • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

            Posté par . Évalué à 2.

            Oups, le bibliothécaire-documentaliste que je suis se réveille avec les mots magiques gestion documentaire.
            Et donc, tu fais cela avec Zope et ZODB. Tu peux en dire plus ? Il y a des démos quelques parts ?
            Je vais faire une petite recherche pour avoir de plus amples infos sur cela, et voir ce que l'on peut faire avec cela !
            • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

              Posté par . Évalué à 3.

              Remarque que j'ai peut-être abusé de ce terme :)

              si les expressions « méta-données, indexation automatique, recherche plein texte workflow, publication, knowledge management* » te parlent également, tu devrais effectivement t'intéresser à Zope.

              Ben pour les démos... si c'est pour jouer avec, installe Zope :)

              Pour des sites en productions, pense à tous les sites publiques et intranet de des administrations nationales/régionales/etc. Les documents de bureautique et compagnie sont stockés, indexés et publiés après suivi d'un workflow de modération.

              (*) Il fallait bien que je place un terme à la 01 informatique :)
              • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                Posté par . Évalué à 3.

                Voui, voui, voui, tout ces termes me parlent beaucoup ;-))
                En fait, je suis occupé actuellement à mettre en place un intranet documentaire ;-))
                Donc, méta-données, indexation automatique, publication, knowledge management (même si cela ne veut rien dire, enfin, pour être plus correct, cela recouvre beaucoup trop de choses).
                Allez, zou, apt-get install zope et je vais me préparer du café pour bouquiner la documentation !
                • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                  Posté par . Évalué à 2.

                  Noooooooooooooon ! pas de paquet Debian pour Zope* !!!

                  Il vaut 100x mieux installer le tgz de zope.org et le gérer soi-même ; et vu la facilité de la chose tu n'as pas d'excuse ! :)

                  Fait gaffe de compulser le Zope Book dans sa version 2.6 cf mon lien dans un autre commentaire. il n'y a que 2 chapitres qui n'ont pas été mis à jour.

                  Sinon une dernière chose, le tutorial (elvis is alive ou je sais plus quoi) aurait été sympa s'il n'avait pas 2 ans de retard.
                  Si tu n'es pas développeur, essaye CPS ou Plone.

                  sur ce...

                  (*) Je ne met pas en cause la qualité de ces paquets ni le travail des mainteneurs, c'est juste par expérience et je n'ai trouvé personne qui préférait les paquets Debian aux binaires ou même sources.
                  • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                    Posté par . Évalué à 3.

                    >Je ne met pas en cause la qualité de ces paquets ni le travail des mainteneurs, c'est juste par expérience et je n'ai trouvé personne qui préférait les paquets Debian aux binaires ou même sources.

                    Et bien pour moi les paquage Debian de Zope (et python) sont indispenssables.

                    Si on va par la, pourquoi installer les paquet Debian de apache, mysql, postgresql, python, PoPy, PygreSQL,...

                    Les paquets Debian sont super bien fait, tout tes fichiers de la distrib (les "statiques") sont dans /usr, les fichiers propre à l'instance sont dans /var/lib/zope et les composants additionels sont dans /var/lib/zope/Products ou /var/lib/zope/instance/{instance}/Products, dans les nouvelles versions des paquets, on à la possibilité de faire plusieurs instances avec le même paquet (sans faire de nouveaux script de démarage).
                    Pour python, les modules suplémentaires sont dans /usr/local/lib/python/2.x/site-paquages/

                    Bréf tout un tat de chose qui font que Debian c'est bien et que c'est pas comme chez les autres.

                    Quand tu vas installer disont dix machines avec Zope et quelques modules. Comment vas se passer l'upgrade chez toi ? Chez moi apt-get update;apt-get upgrade c'est quand même beaucoup plus simple que tar & Cie.
                    • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                      Posté par . Évalué à 3.

                      Pour la gestion documentaire, y a bien C-arbre, qui permet d'avoir un intranet et un internet à la fois et qui dispose d'un paquet debian aussi. mais bon faut un compte sur un serveur mysql, il n'y a pas encore la possibilite d'une base en xml, dur de trouver un truc parfait.

                      http://freshmeat.net/projects/c-arbre(...)
                      • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                        Posté par . Évalué à 1.

                        Je viens de regarder ce projet, et il va falloir que je jette un coup d'oeil plus sérieux !
                        Par contre, avec Zope, il y a moyen de faire tellement de choses que je ne sais pas trop par où commencer ;-(
                        Je suis sûr que cela pourrait m'être utile, mais bon, je vais me contenter du bouquin zope pour le moment. Cela me permettra de me fixer les idées.
                        • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                          Posté par . Évalué à 1.

                          Plutôt que le bouquin essaies de suivre le tutorial. Et si tu veux des résultats immédiats utilise CPS ( http://www.nuxeo.org(...) ). Tu pourras gérer la documentation avec pratiquement n'importe quel type de fichier ( word, excel, pdf, oowrite,..) avec indexation automatique des mots du document, gestion du workflow, versioning, historique, gestion des autorisations,...
            • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

              Posté par (page perso) . Évalué à 1.

              Pour la gestion documentaire, il existe plusieurs point de vue pour Zope.
              Les plus répandus sont Collaborative Portal Server http://nuxeo.org(...) dont la version 3 arrive bientôt, et Plone http://plone.org(...)
              Il y aura une série de conférence sur chacun jeudi lors des RMLL
        • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

          Posté par (page perso) . Évalué à 3.

          Peut-être que ses données vont très bien dans des objets de la base Zope...
        • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

          Posté par (page perso) . Évalué à 1.

          oui avec l'extensions .xml :)
          • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

            Posté par . Évalué à 5.

            [+] c'est le geste qui compte, j'ai plus de votes :)

            m'enfin tout ça pour dire qu'il y a des gens qui voient des SGBDR partout.

            En plus je suis impardonnable de ne pas avoir pensé à XML, je suis en plein cours là-dessus.
            • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

              Posté par . Évalué à 1.

              J'ai une question, ça me turlupine depuis un moment. Avec ces bases objets comment est ce qu'on fait pour remplacer une bonne vieille requête SQL UPDATE pour mettre à jour tous les objets sur le même champ de façon rapide? Utile par exemple sur une montée de version ou il faut réinitialiser une valeur sur tous les objets?
              • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                Posté par . Évalué à 5.

                Dans l'hypothèse où ton cas se résoud bien de cette façon... :

                Il y a un catalogue qui indexe les objets qui s'y conforment (quasi automatiquement) et remet à plat la hiérarchie. Bref t'obtiens une liste de tous tes objets, indexés sur les champs de ton choix.

                L'algo donnerait :

                - demander au catalogue tous les objets de type tonTypeAMettreAJour avec peut-être certaines restriction sur les index pour bien cibler le travail de recherche
                - pour chaque entrée du catalogue:
                - récupérer une référence sur le véritable objet (pas le « brain » que stocke le catalogue)
                - changer la valeur de l'attribut

                les secrets les plus intimes du catalogue et ses indexes sont ici :
                http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Searchi(...)
                (encore plus intime, il y a la lecture du code source :))

                Voilà ! S'il n'y a une aucune exception de soulevée, la transaction a été validée et les attributs ont été mis à jour.

                Tu me dira qu'installer un catalogue pour faire la migration d'objets peut être lourde mais dis-toi :
                - qu'un objet ne se conçoit pas comme une table dans un SGBDR. Tu peux par exemple imaginer une méthode de mise à jour et des assertions pour détecter quand il faut la pratiquer, alors que les nouvelles instances auraient déjà ces assertions de validées (TODO réfléchir à ce que je viens la tête au frais).
                - que souvent tu travailles dans un framework genre CMF/CPS/Plone donc le catalogue est déjà en place et rempli et que t'as des scripts genre cpsupdate qu'on t'invite à lancer pour pratiquer la mise à jour d'une instance de site.
              • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                Posté par . Évalué à 1.

                Le langage OQL (l'équivalent de SQL spécifié par l'ODMG) ne définit pas d'instructions pour modifier la base (donc pas de update ni de create).

                Par contre, les SGBDO fournissent en général des outils pour migrer d'un schéma de base vers un autre. Il n'y a donc pas de manière standardisée de le faire.

                Au pire, on peut écrire ces scripts de migration dans le langage dans le langage de dans lequel on a défini les objets (et donc le modèle de la base): C++, java, python...
                • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                  Posté par . Évalué à 1.

                  D'après vos deux réponses (fort intérressantes) je pense qu'il semble évident qu'un outil comme PostgreSQL devient plus performant dès lors que ces mises à jour de masse sont à la base de l'application, comme dans le cas de traitements de type banquaires, en mode batch, non?
                  J'imagine que la rapidité de mise à jour d'un catalogue objet ne peut pas se comparer à une procédure SQL stockée.

                  Existe-il des benchamrks de bases objets vs base relationnelles sur des applications gérant des grosess masses de données et nécéssitants de fréquentes mises à jour?

                  Ou alors, puisque nous sommes dans les interrogations existentielles, où trouver une base de réflexion sur les différents choix techniques permettant de mettre en place une base de donnée objet ou une base objet en fonction des caractéristiques de l' application? Si quelqu'un dispose de tels éléments qu'il en soit loué à jamais. Mes neurones sont pris d'une faiblesse passagère et j'avoue ne pas avoir le courage de chercher moi-même.
                  • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                    Posté par (page perso) . Évalué à 1.

                    Pour l'écriture, c'est clair que Zope rame. Par contre, il existe des SGBDOO (commerciaux malheureusement), tels qu'ObjectStore, Objectivity qui sont réputés très performants.
                    Mon pif (ne tapez pas dessus) me dit qu'un modèle objet étant plus complexe qu'un modèle relationnel, on doit arriver dans l'absolu à :
                    - de meilleures performances en lecture pour une BDOO (modélisation plus fine, donc requêtes usuelles plus performantes)
                    - de meilleures performances en écriture pour une BDR (structure de fichiers et transactions plus simples à gérer)

                    fredz
              • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

                Posté par (page perso) . Évalué à 1.

                Il y a un langage XML pour ça : XUpdate je crois
                cf XIndice (base de données XML d'Apache, ya http://exist.sourceforge.net/(...) aussi ) :
                It is an XML based language for specifying XML modifications and allows those modifications to be applied to entire document collections as well as single documents.
  • # Re: PoPy et PygreSQL s'unissent pour le meilleur

    Posté par . Évalué à 1.

    c'est marrant comme dans le logiciel libre, les projets se desunissent (forkent comme recemment avec Xfree) ou au contraire s'unissent comme ici
    L'union permet la puissance mais le fork permet la diversite... entre les deux je sais pas ce qui est le mieux...
    Je pense pour l'instant, la puissance peut etre le plus important pour les decideurs presses ou le grand public... Je pense que la diversite est bien, mais peut etre accessoire pour l'instant...
    • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

      Posté par . Évalué à 3.

      Je ne pense pas que l'on doive choisir de façon absolue entre la puissance et la diversité. Chacune de ces options se justifie dans un contexte donné. Comme dis plus haut, la diversité pour un backend n'est pas vraiment justifié ni souhaitable. Par contre, la puissance, oui ! Et toujours comme dis plus haut, pour les windows managers, la diversité y est nettement plus souhaitables.
    • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

      Posté par . Évalué à 1.

      L'important, ce n'est ni la puissance ni la diversité, ou alors ce sont les deux.

      Car l'important, c'est le logiciel libre, qui permet ces deux choses...
      • [^] # Re: PoPy et PygreSQL s'unissent pour le meilleur

        Posté par . Évalué à -1.

        il n'y pas que le logiciel libre qui permettent ces deux choses, le proprietaire le permet aussi a un point de vu plus commercial...
        dans mon message precedent je voulais juste dire que pour l'instant peut etre que la puissance (chez linux et les logiciels libres) est surement plus un argument pour les neophytes que la diversite ( qui n'a jamais entendu "je veus me lancer dans linux mais j'hesite : mandrake ? red hat ? debian ? slackware ? ....)
        J'espere m'etre fait comprendre cette fois ci...
  • # Re: PoPy et PygreSQL s'unissent pour le meilleur

    Posté par (page perso) . Évalué à 3.

    Il existe également l'excellent psycopg : http://initd.org/software/initd/psycopg(...)
    Compatible Python DBAPI-2.0 (entre autres, support des curseurs), sensé être plus rapide (utilisation du module psyco : http://psyco.sourceforge.net(...) ), et surtout très actif.
    Un DA Zope existe, je l'utilise en production depuis plus d'un an.

    fredz
  • # Icone obsolète

    Posté par (page perso) . Évalué à 1.

    Il me semble que l'icone Beopen / Python est obsolète. L'icone semble d'ailleurs dater de l'époque startup. L'aventure de Guido dans cette société est fini depuis longtemps, il me semble ...

    Mickaël

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.