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.
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 :)
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 !
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 :)
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 !
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.
>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.
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.
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.
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,...
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
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?
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
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.
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...
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.
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)
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.
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...
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.
pour les windows managers, la diversité y est nettement plus souhaitables.
Du moment qu'ils respectent certains standards permettant l'interropérabilité. http://www.freedesktop.org/(...)
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...
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.
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 ...
# Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Willou (site web personnel) . Évalué à 4.
Bye & bonne fusion,
Willou.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Ramso . Évalué à 6.
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 _seb_ . Évalué à -2.
Tes données, tu les enregistres dans des fichiers txt ?
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Ramso . Évalué à 5.
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 saorge . Évalué à 2.
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 Ramso . Évalué à 3.
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 saorge . Évalué à 3.
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 Ramso . Évalué à 2.
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 cortex . Évalué à 3.
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 Dalton joe . Évalué à 3.
http://freshmeat.net/projects/c-arbre(...)
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par saorge . Évalué à 1.
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 bricabrac . Évalué à 1.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 1.
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 Fabimaru (site web personnel) . Évalué à 3.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par _alex . Évalué à 1.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Ramso . Évalué à 5.
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 Rage . Évalué à 1.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Ramso . Évalué à 5.
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 Gérald Quintana . Évalué à 1.
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 Rage . Évalué à 1.
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 fredzz (site web personnel) . Évalué à 1.
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 _alex . Évalué à 1.
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 mamelouk . Évalué à 1.
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 saorge . Évalué à 3.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par wismerhill . Évalué à 2.
Du moment qu'ils respectent certains standards permettant l'interropérabilité.
http://www.freedesktop.org/(...)
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Anonyme . Évalué à 1.
Car l'important, c'est le logiciel libre, qui permet ces deux choses...
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par mamelouk . Évalué à -1.
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 linuxidable . Évalué à 1.
Nooonn, Suse bien sûre !
# Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par fredzz (site web personnel) . Évalué à 3.
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 Mickaël Rémond (site web personnel) . Évalué à 1.
Mickaël
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.