Votre avis sur Elixir

Salut !

Tu veux parler l'élixir suivant :
http://www.coop-bioethic.com/details_article.php?numA2
?
(en orm de 10 ml)

--
@-salutations

Michel Claveau

On Jun 11, 11:46 am, chris <cbon...@sra.fr> wrote:

Bonjour,

ya t il des courageux

Pourquoi "courageux" ?

qui utilise Elixir l'excellllllent ORM ?

Disons plutôt l'excellente surcouche à SQLAlchemy...

et qu'en pensez vous ?

Pour le moment, plutôt du bien...

si vous avez des retour d'experience,

Un peu tôt encore...

idéee remarques ...

Tu penses à quoi ?

En ce qui concerne SQLAlchemy, le peu d'expérience que j'ai (quelques
plugins Trac pour un intranet) est très concluant, mais il faudrait
tester sur de plus gros volumes de données et de plus grosses charges.
En ce qui concerne Elixir, c'est avant tout une surcouche déclarative
largement inspirée des ActiveRecords de Rails, qui simplifie certains
aspects de l'utilisation de SQLAlchemy comme ORM, mais de fait (et
pour le moment) limite pas mal les possibilités de ce dernier.

Mes deux centimes...

Salut !

Tu veux parler l'élixir suivant :
http://www.coop-bioethic.com/details_article.php?numA2
?
(en orm de 10 ml)

Facile ;-)

Nan celui la python elixir : http://cheeseshop.python.org/pypi/Elixir/

A+
chris

Bonjour,

Pourquoi "courageux" ?

Parce c'est tout neuf apparemment ..

qui utilise Elixir l'excellllllent ORM ?

Disons plutôt l'excellente surcouche à SQLAlchemy...

Ok

et qu'en pensez vous ?

Pour le moment, plutôt du bien...

Ben moi aussi

si vous avez des retour d'experience,

Un peu tôt encore...

je me disais aussi ...

idéee remarques ...

Tu penses à quoi ?

En ce qui concerne SQLAlchemy, le peu d'expérience que j'ai (quelques
plugins Trac pour un intranet) est très concluant, mais il faudrait
tester sur de plus gros volumes de données et de plus grosses charges.
En ce qui concerne Elixir, c'est avant tout une surcouche déclarative
largement inspirée des ActiveRecords de Rails, qui simplifie certains
aspects de l'utilisation de SQLAlchemy comme ORM, mais de fait (et
pour le moment) limite pas mal les possibilités de ce dernier.

Mes deux centimes...

A avoir un avis différent, je commence tout juste a tester le truc et

pour l'instant cela va plutot bien (sans parler de volume)
mais juste de facilité d'utilisation, souplesse et puissance

Le fait que cela s'inspire d'Active Record est bien car pour avoir fait
un peu de rails c'est ce que je regrette le plus par rapport à python
qui n'a pas encore d'equivalent rail pour moi mais bon cela va venir
En fait ce qui m'a detourné de rails vers python c'est les acces bas au
bdd "commerciale" Oracle et consort qui sont tres vite des usines a gaz
des lors que l'on sort de linux

En fait je trouvais surprenant que peu de gens parle de Elixir et en
fait je me disais qu'il y avait peut etre une autre ORM

Voila
Merci
A+
chris

Salut,

il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.

Pour ma part je suis habitué à l'ORM de Django qui répond parfaitement
à mes modestes besoins (en termes de compexité de schéma et requête,
mais pas de performance ni de volume).

Au fait, toi qui cherche un équivalent à RoR, Django
(djangoproject.com) est à mon avis bien supérieur à différents
niveaux.

Mais comme l'évangélisme n'est pas ma tasse de thé, je te laisse
découvrir la bête ...
... après ça, reviens poser des questions sur Django quand tu veux,
j'y répondrais de mon mieux.

Olive.

Bonjour,

(snip)

qui utilise Elixir l'excellllllent ORM ?
si vous avez des retour d'experience,
idéee remarques ...

(snip)

En ce qui concerne SQLAlchemy, le peu d'expérience que j'ai (quelques
plugins Trac pour un intranet) est très concluant, mais il faudrait
tester sur de plus gros volumes de données et de plus grosses charges.
En ce qui concerne Elixir, c'est avant tout une surcouche déclarative
largement inspirée des ActiveRecords de Rails, qui simplifie certains
aspects de l'utilisation de SQLAlchemy comme ORM, mais de fait (et
pour le moment) limite pas mal les possibilités de ce dernier.


A avoir un avis différent, je commence tout juste a tester le truc et

pour l'instant cela va plutot bien (sans parler de volume)
mais juste de facilité d'utilisation, souplesse et puissance

L'essentiel vient de SQLAlchemy, qui est bien plus qu'un ORM.

Le fait que cela s'inspire d'Active Record est bien car pour avoir fait
un peu de rails c'est ce que je regrette le plus par rapport à python
qui n'a pas encore d'equivalent rail

Regarde du côté de Pylons, qui a repris une bonne partie de ce qui est
bon dans Rails.

pour moi mais bon cela va venir
En fait ce qui m'a detourné de rails vers python c'est les acces bas au
bdd "commerciale" Oracle et consort qui sont tres vite des usines a gaz
des lors que l'on sort de linux

En fait je trouvais surprenant que peu de gens parle de Elixir et en
fait je me disais qu'il y avait peut etre une autre ORM

Once again et au risque de me répéter, Elixir n'est qu'une (mince)
surcouche sur la partie ORM de SQLAlchemy - un des intérêts de
SQLAlchemy étant que c'est d'abord une bibliothèque visant à une
meilleure intégration entre Python et les bases SQL. Pour ma part, j'ai
utilisé la partie "basse" de SQLAlchemy pour des plugins Trac, et rien
qu'à ce niveau là c'est déjà un bonheur comparé à la DB-API.

Concernant le côté ORM, je reste pour le moment assez partagé. Les
quelques essais que j'ai fait avec SQLObject ne m'ont pas convaincu, et,
s'il y a manifestement des choses très intéressantes dans ActiveRecords,
il y a aussi quelques inepties qui dénotent AHMA d'une grande
incompréhension des bases relationnelles et rendent l'outil limite
inutilisable pour n'importe quelle application de gestion un tant soit
peu sérieuse. SQLAlchemy ne souffre pas de ces mêmes limitations, bien
au contraire. Bref, la question pour moi est surtout de savoir (ce que
dira l'expérience) si Elixir permet de continuer à profiter de toute la
puissance de SQLAlchemy sans entrainer d'incohérences ou de duplications...

Salut,

il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.

Pour ma part je suis habitué à l'ORM de Django qui répond parfaitement
à mes modestes besoins (en termes de compexité de schéma et requête,
mais pas de performance ni de volume).

Au fait, toi qui cherche un équivalent à RoR, Django
(djangoproject.com) est à mon avis bien supérieur à différents
niveaux.

Mais comme l'évangélisme n'est pas ma tasse de thé, je te laisse
découvrir la bête ...
... après ça, reviens poser des questions sur Django quand tu veux,
j'y répondrais de mon mieux.

Olive.

J'ai decouvert django j'ai un petit peut testé pour voir la bete

c'est bien mais j'ai pas compris certaine choses
Par exemple : le coté admin => c'est génial mais moi je veux
la même chose coté utilisateur et je comprends pas
la plupart des tutoriels explique comment developper des templates mais
c'est pas genial
Bon comme je suis pas pressé j'attends un peu la maturité

A+
chris

Regarde du côté de Pylons, qui a repris une bonne partie de ce qui est
bon dans Rails.

Cela fait plusieurs fois que j'ouie dire du bien de Pylons faut que j'essaie

Once again et au risque de me répéter, Elixir n'est qu'une (mince)
surcouche sur la partie ORM de SQLAlchemy - un des intérêts de
SQLAlchemy étant que c'est d'abord une bibliothèque visant à une
meilleure intégration entre Python et les bases SQL. Pour ma part, j'ai
utilisé la partie "basse" de SQLAlchemy pour des plugins Trac, et rien
qu'à ce niveau là c'est déjà un bonheur comparé à la DB-API.

Concernant le côté ORM, je reste pour le moment assez partagé. Les
quelques essais que j'ai fait avec SQLObject ne m'ont pas convaincu, et,
s'il y a manifestement des choses très intéressantes dans ActiveRecords,
il y a aussi quelques inepties qui dénotent AHMA d'une grande
incompréhension des bases relationnelles et rendent l'outil limite
inutilisable pour n'importe quelle application de gestion un tant soit
peu sérieuse. SQLAlchemy ne souffre pas de ces mêmes limitations, bien
au contraire. Bref, la question pour moi est surtout de savoir (ce que
dira l'expérience) si Elixir permet de continuer à profiter de toute la
puissance de SQLAlchemy sans entrainer d'incohérences ou de duplications...

En fait que ce sois SQLAlchemy ou SQLOBject ce qui manque c'est des
exemples autres que insert et select (je comprend aussi que c'est pas la
partie la plus marrante a faire :) )

Ainsi j'ai eu un peu de mal a comprendre certaine notamment comment on
utilise les objects retournés par les requetes et l'appel de certaine
fonctions

Avec des choses plus compliqué du style ( update ... where truc=1 )
ou tout ce qui fait la beauté de sql
J'ai bien essayé de parcourir les sources mais je manquent de reflexes
en python pour le faire sans perdre trop de temps
Alors je faineante et cherche plus simple
Et a force de chercher on trouve :)

Bon merci pour ces infos précieuse le fait d'en discuter et de l'ecrire
dans ce ng oblige à réfléchir sur le sujet et permet d'aller plus loin
que la lecture du tutorial

Encore Merci
A+
chris

le 12.06.2007 16:58 chris a écrit:

En fait que ce sois SQLAlchemy ou SQLOBject ce qui manque c'est des
exemples autres que insert et select (je comprend aussi que c'est pas la
partie la plus marrante a faire :) )

Ainsi j'ai eu un peu de mal a comprendre certaine notamment comment on
utilise les objects retournés par les requetes et l'appel de certaine
fonctions

Avec des choses plus compliqué du style ( update ... where truc=1 )
ou tout ce qui fait la beauté de sql

C'est une grande partie de (tout ?) l'intérêt des ORM... On ne fait plus
de SQL :), on manipule des objets sans (trop) se poser de questions.

Les updates, deletes voire certains selects sont faits implicitement au
moment où on va chercher l'attribut d'un objet (select) ou lors du flush
de la session (qu'on pourrait comparer à un commit) après avoir modifié
certains attributs de certains objets.

Prenons un petit exemple très simple de 2 objets avec un lien 1,n entre
eux (et on va utiliser la syntaxe de Elixir pour ça)

class Groupe(Entity):
has_field('nom', Unicode(64))
has_many('elements', of_kind='Element')

class Element(Entity):
has_field('numero', Integer)
belongs_to('groupe', of_kind='Groupe')

donc des groupes et des elements dans les groupes

ca va generer qq chose comme
create table groupe (
id integer not null,
nom varchar(64)
);
create table element (
id integer not null,
numero integer,
groupe_id integer);
et une contrainte de foreign_key sur groupe_id...
(les id sont ajoutés automatiquement par elixir si on n'a pas défini
soit même de clé primaire)

Maintenant, il suffit de faire
groupe_1 = Groupe(nom="groupe 1")
groupe_2 = Groupe(nom="groupe 2")

elt_1 = Element(numero=1, groupe=groupe_1)
elt_2 = Element(Numero=2, groupe=groupe_1)
elt_3 = Element(numero=3)
groupe_2.elements.append(elt_3)
# qu'on aurait pu aussi écrire elt_3.groupe = groupe_2

au moment du session.flush()
SQLAlchemy va generer les ordres d'insert qui vont bien...

Si ensuite on fait un elt_1.groupe = groupe_2 suivi d'un flush on aura
"gratis" l'update de la table.
Remarquons aussi qu'exécuter elt_1.groupe = groupe_2 va mettre à jour
immédiatement les listes groupe_2.elements (ajout de l'element) et
groupe_1.elements (suppression de l'element) puisque c'est une relation 1,n.

Quant aux selects implicites voici un exemple :
supposons qu'on ait laissé la base dans l'état précédent et qu'on
relance python...
allons chercher le premier groupe
g1 = Groupe.get_by(Groupe.c.nom=="groupe 1")

ca génère le select (genre select * from g1 where nom="groupe 1")
celui-ci, on l'a bien décrit de manière assez explicite (selct_by) ;-)

et maintenant tapons
g1.elements

ce simple appel (la première fois qu'on va faire cet appel) va générer
un select du genre "select * from element where groupe_id = 1".
Celui-là SQLAlchemy l'a généré tout seul....

évidement, le select * va en faire hurler plus d'un (mois le premier
dans certains cas)... Rassurez-vous, on peut demander à SQLAlchemy de
retarder la récupération de certains champs jusqu'à ce qu'on y fasse
référence explicitement.... Mais ça sort du petit exemple d'aujourd'hui.

J'ai bien essayé de parcourir les sources mais je manquent de reflexes
en python pour le faire sans perdre trop de temps
Alors je faineante et cherche plus simple
Et a force de chercher on trouve :)

Bon merci pour ces infos précieuse le fait d'en discuter et de l'ecrire
dans ce ng oblige à réfléchir sur le sujet et permet d'aller plus loin
que la lecture du tutorial

Encore Merci
A+
chris

Salut,

il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.

Et notoirement plus limité.

Pour ma part je suis habitué à l'ORM de Django qui répond parfaitement
à mes modestes besoins (en termes de compexité de schéma et requête,
mais pas de performance ni de volume).

Au fait, toi qui cherche un équivalent à RoR, Django
(djangoproject.com) est à mon avis bien supérieur à différents
niveaux.

Heu... Tu as réellement développé quelque chose (je veux dire, de
non-trivial) avec Rails ?

Django partage avec Rails l'inconvénient d'être un monolithe. En dehors
de ça - et bien que Django soit un très bon produit dans son genre -,
j'avoue ne pas voir où est la "supériorité".