- Topia-devel - mailman.cloud.codelutin.com

Events sur hibernate
by Eric Chatellier Nov. 1, 2007

Nov. 1, 2007

Salut, J'ai vérifié si la dernière version d'hibernate reglait le problème de l'héritage des events. En fait, ils ont réglé le problème pour les Post*Event, mais pas pour les Pre*Event :). J'ai repatché la dernière version, et uploadé sur lutinbuilder avec un pom correct, mais je l'ai pas intégré à ToPIA. Eric.

1 0

[DMS] Mise à jour de la base
by Sebastien EON March 16, 2007

March 16, 2007

Parmi, les autres problèmes détectés, la question de la méthode de mise à jour se pose aussi. Solution 1 : API ---------------- Nous étions partis sur la génération automatique d'un moule de classe Java par un outils genre LutinGenerator, ou notre propre projet... Cette classe générée utiliserait des fonctions que nous développerions pour effectuer ces modifications : Par exemple : * renommer une table * supprimer un attribut * ... Cela permet aussi d'insérer du code pour effectuer des mises à jour complexes spécifiques ; par exemple, la transformation d'un table en objet complexe MatrixType. Solution 2 : DynaBeans ---------------------- L'autre solution évoquée lors de la première solution concernait l'utilisation des dynabeans via hibernate. Mais les quelques recherches effectuées ne nous permettent apparemment pas de récupérer un beans sur une table en base par exemple. Comment conserver l'abstraction d'hibernate pour découvrir le schéma en base, sans disposer des classes du mapping d'origine. Nous sommes ouverts aux critiques sur ces deux solutions, pour pouvoir choisir la solution la plus adaptée pour ce projet. Benjamin, Eric, Sébastien, Vincent

4 6

[DMS] Problème de détection de version
by Sebastien EON Jan. 31, 2007

Jan. 31, 2007

Bonjour, Parmi les différents problèmes rencontrés sur le projet, se pose celui de la détection de la version de la base. Il nous parait nécessaire d'avoir cette information dans la base et non, en local. Donc, nous pouvons par exemple : - avoir une table contenant la version de la base (solution simple) - autre chose, (propositions ...) De plus, nous sommes tombés sur votre page http://topia.labs.libre-entreprise.org/SchemaMigration.html. où vous dites que le stockage du numéro de version dans la base est un désavantage... Benjamin, Eric, Sébastien, Vincent

2 1

resolution de topia qui ne genere pas
by Benjamin POUSSIN Sept. 21, 2006

Sept. 21, 2006

Salut, J'ai trouvé pourquoi certaine version de topia ne genere pas :). Et bien ce vient d'eclipse, et oui. lorsque l'on compile topia, le preprocessor passe sur les templates pour remplacer les /*# par des out.println. Or si l'on modifie le templates, eclipse recompile le source et le place dans target/classes, sans passé le preprocessor on se retrouve alors avec des commentaires a la place des out.printlns :(. Avant de packager topia (et tout ce qui utilise le preproc) il faut bien penser a faire un clean. mvn clean compile ... pour etre sur que ce sont les class preprocesser que l'on a et non les classes eclipses. Une autre facon de faire est de dire a eclipse de compiler dans un autre repertoire que maven. -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

1 0

Re: [Topia-cvscommit] [topia2] src/java/org/codelutin/topia/persistence
by Benjamin POUSSIN Sept. 4, 2006

Sept. 4, 2006

On Mon, 4 Sep 2006 11:55:27 +0200 (CEST) ruchaud(a)users.labs.libre-entreprise.org wrote: > + public Criteria createCriteria(FlushMode mode) throws TopiaException { > + return getParentDAO().createCriteria(mode); > + } euh, vous etes sur que passer le FlushMode en parametre est vraiment utile ? Il n'y a pas un moyen de faire la meme chose sans ? Car et plus generalement (mais pas forcement pour tout de suite) reflechir a ces imports import org.hibernate.Criteria; import org.hibernate.FlushMode; import org.hibernate.criterion.Criterion; import org.hibernate.criterion.Projection; dans TopiaDAO.java qui devrait etre independant de la persistence -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

2 1

[ToPIA][Chorem] Proposition sur la sécurité
by Julien Ruchaud Aug. 16, 2006

Aug. 16, 2006

Proposition sur la sécurité =========================== Contexte -------- Actuellement, la sécurité dans ToPIA se fait par JAAS. Elle propose la gestion de permission sur les entités ToPIA, droit en lecture, écriture, création et chargement. La gestion des droits fonctionne correctement. Mais elle semble ne pas être adaptée à la problèmatique du projet Chorem. Le projet Chorem a besoin de plus de souplesse dans l'écriture des permissions. Inversion de permission ------------------------ En sécurité, il existe deux stratégies pour la création des permissions : - la première consiste à interdire l'accès à l'ensemble des données et d'autoriser au cas par cas - la deuxième consiste à autoriser l'accès à l'ensemble des données et d'interdire au cas par cas Le framework ToPIA ne permet que d'utiliser la première stratégie. Il semble aussi important de proposer la deuxième stratégie. Lien entre permissions ---------------------- Un lien entre permissions consite à spécifier qu'une permission est la copie d'une autre permission sur des entités différentes. L'utilité d'un tel mécanisme est la propagation des modifications des droits sur la permission. Exemple sur un arbre, tous les noeuds vont avoir les mêmes droits que le noeud racine. En cas de modification sur le noeuds racine, automatiquement l'ensemble des noeuds de arbre vont changer de droit. L'avantage est notable, il n'est plus nécessaire de prendre l'ensemble des permissions des noeuds pour leur notifier les changements. LinkPermission : - id (* ou TopiaId) - link (permission ou principal ?) - principals Permission de type association ------------------------------ On va partir d'un exemple : |--------| 1 * |-------| | Projet |----------------| Tâche | |--------| contient |-------| On souhaiterait spécifier qu'un utilisateur à aucune restriction sur l'ensemble des projets. Et il n'a la permission de créer des sous-tâches seulement dans le projet «essai». Utilisation d'EntityPermission ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On peut spécifier que la première partie ALL - * Project, mais la deuxième partie ne pourra pas être défini. Utilisation de LinkPermission ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On va avoir tendance à écrire : - EntityPermissionName = CREATE - essai Project - LinkPermissionName = * Task - EntityPermissionName Attention, ce n'est pas ce que l'on veut. On vient de dire que l'on a la permission de création sur toutes les tâches (CREATE * Task). AssociationPermission ~~~~~~~~~~~~~~~~~~~~~ L'exemple précédent à mis en évidence un manque. Les permissions de type association répondent à ce type de problème. Elles consitent à donner une permission par rapport à une autre entité par le biais d'une association. Dans le cas d'une action de modification, de suppression ou de chargement, les permissions de type association peuvent être remplacées par des permissions de type entité. En effet, les permissions de type association ne sont qu'une virtualisation d'un ensemble d'entité, pour lesquelles on associe des permissions. Attention, les permissions de type association sont caractérisées par leur sens de navigation. Le cas de la récursivité des associations n'est pas traité car cette caractéristique est compliquée à mettre en oeuvre. L'utilisation de lien entre permissions est recommandé de ce type cas. AssociationLink : - id (* ou TopiaId) - association (name) - actions (ALL, CREATE, UPDATE, DELETE et LOAD) - reverseId (* ou TopiaId) - principals En applicant, ce nouveau type de permission sur l'exemple précédent, on obtient : essai Project - contient - CREATE - * Task. C'est à dire qu'on a la permission de création si c'est le projet essai qui contient les nouvelles tâches. ----------------------------------------------------------- Julien Ruchaud

1 0

Bilan Import/Export XML
by Arnaud Thimel May 10, 2006

May 10, 2006

Salut, J'ai bossé un peu sur l'import/export en XML. J'ai commité mes modifs mais le bilan n'est pas très bon. Export Lorsque le modèle comporte une relation 1-n, l'export plante a cause d'une ClassCastException. Les collections sont mappées telles que : <bag name="blabla" lazy="true" node="blabla" embed-xml="true"> <key column="calendar"/> <one-to-many class="org.codelutin.test.BlablaImpl" node="topiaId" embed-xml="false"/> </bag> (le champ embed-xml sert à indiquer s'il faut imbriquer le contenu ce qui est déconseillé mais peut-etre nécessaire pour les collections) Ce qui donne à l'export : <monEntity topiaId="jdlqklsjdlqskjd"> <blabla> <topiaId>blabla#123#1</topiaId> <topiaId>blabla#123#2</topiaId> </blabla> </monEntity> Import J'ai des ClassCastException des que le XML contient des liens entre des entités. Je pense qu'Hibernate considère mon 'blabla#123#1' comme mon entité et non comme son topiaId. Ce qui me fait dire que le XML généré devrait être tel que : <monEntity topiaId="jdlqklsjdlqskjd"> <blablas> <blabla topiaId="blabla#123#1"/> <blabla topiaId="blabla#123#2"/> </blablas> </monEntity> ... mais je n'ai pas réussit à obtenir ceci. Tout ce que j'ai pu obtenir c'est : <monEntity topiaId="jdlqklsjdlqskjd"> <blabla>blabla#123#1</blabla> <blabla>blabla#123#2</blabla> </monEntity> ... ce qui est mieux mais je pense insuffisant (à vérifier tout de même). Enfin, dernier point, pour un modèle ultra simple (sans 1-n et sans relation entre les entités (paye ton modèle !)) l'export se fait sans encombre et l'import "semble" se faire sans encombre. Cependant, aucun insert n'est fait pas Hibernate et aucune entité n'est ensuite visible dans la base... :( Arno.

1 0

[Annonce] Nouvelle version de ToPIA 2.0.4
by Arnaud Thimel March 3, 2006

March 3, 2006

Bonjour, une nouvelle version de ToPIA a été déployée. Au programme (depuis la 2.0.3) : * Correction du support des interfaces et classes abstraites (conjointement à LutinGenerator 0.30) * Ajout des exceptions sur le operations (conjointement à LutinGenerator 0.30) Le plugin ToPIA a été mis à jour, il est téléchargeable par la commande : maven -DgroupId=lutinlib -DartifactId=maven-topia-plugin -Dversion=2.0.4 plugin:download Cordialement, -- Arnaud Thimel Société Code Lutin - http://www.codelutin.com

1 0

probleme de transaction avec hsql
by Benjamin POUSSIN March 3, 2006

March 3, 2006

Salut, J'ai peut-etre une piste pour le probleme d'isolation de transaction avec hsql :). Il ne sait pas faire :) Comparison to Other Database Engines Feature H2 HSQLDB Derby Daffodil MySQL PostgreSQL Embedded Mode Yes Yes Yes Yes No No Performance (Embedded) Fast Fast Slow Slow N/A N/A Performance (Server) Fast Fast Slow Slow Slow Slow Transaction Isolation Yes No Yes Yes Yes (InnoDB) Yes Cost Based Optimizer Yes No Yes Yes Yes Yes Clustering Yes No No No Yes (Memory) Yes (PGCluster) Encrypted Database Yes No Yes No No No Footprint (jar/dll size)~ 1 MB ~ 600 KB ~ 2 MB ~ 3 MB ~ 4 MB ~ 6 MB Donc il faudrait pouvoir passer a H2. Et donc faire tous les tests unitaires dessus pour voir. -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

1 0

Langage de requete pour les collections
by Benjamin POUSSIN Dec. 5, 2005

Dec. 5, 2005

Salut, Arnaud, on peut peut-etre utiliser josql a la place de lutinquerycollection http://josql.sourceforge.net/ il semble remplir tous les besoins que l'on a pour l'instant. Si tu pouvais prendre un peu de temps pour l'evaluer (a la place de lutinquerycollection) et de faire un petit topo dans le wiki sur ce qui va et va pas. (grand max 1/2 integration comprise :) -- Benjamin -------------------- email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

1 0