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

[Vote] ToPIA-test dans le projet ToPIA
by tony Chemit Jan. 15, 2009

Jan. 15, 2009

Salut les lutins, je me demandais pourquoi le projet ToPIA-test était tout seul dans son coin alors qu'il me parrait plus naturel de le mettre en tant que module du projet ToPIA. L'intérêt serait de pouvoir vérifier qu'une modification dans les générateurs de ToPIA-persistence ne provoque pas de régression sur un modèle xmi. Les votes sont ouverts pendant 72 heures :) (on se la fait à la maven?) [+1] yes do it [0] don't care [-1] No, I'm against it! +1 Tony.

1 0

embed-xml="true" or not ?
by tony Chemit Jan. 14, 2009

Jan. 14, 2009

Salut les lutins, je comprends pas trop un point dans la generation du mapping hibernate sur des associations : dans la méthode generateHibernateOneToMany : on a : si !indexed alors embed-xml="true" sinon embed-xml="false" y'a une subtilité ? car quand on veut faire un export xml ça marche pas bien avec embed-xml="true" tony.

2 1

Re: [Topia-devel] [Dev] How to pour Topia
by Stephane Chorlet Dec. 19, 2008

Dec. 19, 2008

Julien Ruchaud a écrit : > Je suis en train de faire un peu de doc pour Topia. Je voulais votre > avis dessous. Est-ce qu'il manque quelques choses ? Faut-il plus > détailler ? > > How to > ====== > > Ce document a pour objectif de prendre en main le framework Topia. Le > document est constitué de 4 parties, la modèlisation, la génération, la > configuration et l'utilisation. > > Modélisation > ------------ > > La première étape constiste à réaliser le modèle UML soit avec Argouml > soit avec Poséidon. > >>>> Capture d'écran > > Le stérotype «entity» sur les classes permet de préciser que la classe > est persister par Topia. D'autre stérotypes (extern, service, ...) sont > disponiples mais ne sont pas présenté. > > Le fichier de modélisation peut être compléter par un fichier de > configuration nommé <nom fichier modélisation>.properties. Il contient > des informations techniques propres au librairie utilisé par topia. > >>>> Exemple de fichier de configuration + explications + convention de >>>> nommage > > Génération > ---------- > > La génération des fichiers Topia se font par l'utilisation d'un plugin > maven. Le plugin est disponnible sur le repository maven de code lutin > à l'adresse suivante >>> www. > > Exemple de configuration du plugin maven + explication > > Généralement pour une classe modélisé, nous retrouvons 6 fichiers : > * Une interface > >>> Exemple > * Une classe abstraite > >>> Exemple > * Une implantation > >>> Exemple > * Une configuration hibernate > >>> Exemple > * DAO abstrait > >>> Exemple > * DAO > >>> Exemple > > Une classe Helper est aussi générée, permettant l'accès à l'ensemble > des DAO. > > Configuration > ------------- > > Un fichier contenant les informations de connexion à la base de données > et de configuration de Topia doit être créé au niveau des ressources du > projet. > >>>> Exemple de fichier de configuration + explications > > Utilisation > ----------- > > Implantation des méthodes > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > Si des méthodes ont été définis dans le modèle de données il faut créer > l'implantation correspondante. Le paquetage doit porter le même nom que > celui de la génération. > > Gestion des transactions > ~~~~~~~~~~~~~~~~~~~~~~~~ > >>>> Properties conf = >>>> Resource.getConfigProperties("/TopiaContext.properties"); > > Permet de charger un fichier contenant les informations de connexion à > la base et de configuration de Topia. > >>>> TopiaContext rootContext = TopiaContextFactory.getContext(conf); > > Récupère le context de départ pour la création de sous context pour la > gestion des entités. > >>>> TopiaContext transaction = rootContext.beginTransaction(); > > Création d'un sous context pour la gestion des entités. > >>>> transaction.commitTransaction(); > > Validation de l'état du context, les modifications des entités sont > reportées dans la base de données. > >>>> transaction.rollBackTransaction(); > > Invalidation de l'état du context, les modifications des entités ne > sont pas reportées dans la base de données. > >>>> transaction.closeContext(); > > Fermeture d'un sous context et de ses sous contexts. s'il y a une transaction en cours et qu'on ferme le contexte: transaction = context.beginTransaction(); ... transaction.closeContext(); est ce que le closeContext() fait un commit ou un rollback ? > >>>> rootContext.commitTransaction(); > > Fermeture du context principal et de ses sous contexts. C'est quoi la différence entre : transaction.commitTransaction(); et context.commitTransaction(); > > Manipulation des entités > ~~~~~~~~~~~~~~~~~~~~~~~~ > >>>> PersonDAO personDAO = <nom modele>Helper.getPersonDAO(transaction); > > Récupération d'un DAO pour accéder à une entité. > >>>> Person person = personDAO.findByTopiaId(id); > > Les méthodes find permettent de récupérer une ou plusieurs selon > différents critères. > >>>> person.setName("tutu"); > > Manipulation de l'entité par les getters et setters. > >>>> Person person = personDAO.create(); Est ce qu'on peut faire : Person personne = new PersonConcrete() ? > > Création d'une entité. > >>>> personDAO.update(person); > > Modification d'un entité. Est ce qu'on peut faire : transaction = context.beginTransaction(); Person person = personDAO.create(); person.set...(...); personDAO.update(person); person.set...(...); personDAO.update(person); transaction.commitTransaction(); > >>>> personDAO.delete(person); > > Suppression d'une entité. > _______________________________________________ > Dev mailing list > Dev(a)list.codelutin.com > http://list.codelutin.com/cgi-bin/mailman/listinfo/dev >

4 7

How to pour Topia
by Julien Ruchaud Dec. 18, 2008

Dec. 18, 2008

Je suis en train de faire un peu de doc pour Topia. Je voulais votre avis dessous. Est-ce qu'il manque quelques choses ? Faut-il plus détailler ? How to ====== Ce document a pour objectif de prendre en main le framework Topia. Le document est constitué de 4 parties, la modèlisation, la génération, la configuration et l'utilisation. Modélisation ------------ La première étape constiste à réaliser le modèle UML soit avec Argouml soit avec Poséidon. >>> Capture d'écran Le stérotype «entity» sur les classes permet de préciser que la classe est persister par Topia. D'autre stérotypes (extern, service, ...) sont disponiples mais ne sont pas présenté. Le fichier de modélisation peut être compléter par un fichier de configuration nommé <nom fichier modélisation>.properties. Il contient des informations techniques propres au librairie utilisé par topia. >>> Exemple de fichier de configuration + explications + convention de >>> nommage Génération ---------- La génération des fichiers Topia se font par l'utilisation d'un plugin maven. Le plugin est disponnible sur le repository maven de code lutin à l'adresse suivante >>> www. Exemple de configuration du plugin maven + explication Généralement pour une classe modélisé, nous retrouvons 6 fichiers : * Une interface >>> Exemple * Une classe abstraite >>> Exemple * Une implantation >>> Exemple * Une configuration hibernate >>> Exemple * DAO abstrait >>> Exemple * DAO >>> Exemple Une classe Helper est aussi générée, permettant l'accès à l'ensemble des DAO. Configuration ------------- Un fichier contenant les informations de connexion à la base de données et de configuration de Topia doit être créé au niveau des ressources du projet. >>> Exemple de fichier de configuration + explications Utilisation ----------- Implantation des méthodes ~~~~~~~~~~~~~~~~~~~~~~~~~ Si des méthodes ont été définis dans le modèle de données il faut créer l'implantation correspondante. Le paquetage doit porter le même nom que celui de la génération. Gestion des transactions ~~~~~~~~~~~~~~~~~~~~~~~~ >>> Properties conf = >>> Resource.getConfigProperties("/TopiaContext.properties"); Permet de charger un fichier contenant les informations de connexion à la base et de configuration de Topia. >>> TopiaContext rootContext = TopiaContextFactory.getContext(conf); Récupère le context de départ pour la création de sous context pour la gestion des entités. >>> TopiaContext transaction = rootContext.beginTransaction(); Création d'un sous context pour la gestion des entités. >>> transaction.commitTransaction(); Validation de l'état du context, les modifications des entités sont reportées dans la base de données. >>> transaction.rollBackTransaction(); Invalidation de l'état du context, les modifications des entités ne sont pas reportées dans la base de données. >>> transaction.closeContext(); Fermeture d'un sous context et de ses sous contexts. >>> rootContext.commitTransaction(); Fermeture du context principal et de ses sous contexts. Manipulation des entités ~~~~~~~~~~~~~~~~~~~~~~~~ >>> PersonDAO personDAO = <nom modele>Helper.getPersonDAO(transaction); Récupération d'un DAO pour accéder à une entité. >>> Person person = personDAO.findByTopiaId(id); Les méthodes find permettent de récupérer une ou plusieurs selon différents critères. >>> person.setName("tutu"); Manipulation de l'entité par les getters et setters. >>> Person person = personDAO.create(); Création d'une entité. >>> personDAO.update(person); Modification d'un entité. >>> personDAO.delete(person); Suppression d'une entité.

1 0

bug probable sur ToPIA-persistence
by tony Chemit Nov. 30, 2008

Nov. 30, 2008

Salut, Il semblerait bien qu'il y a un petit bug dans Topia-persistence : les comportements diffèrent lors d'un commit sur un sous-contexte selon l'opération effectuée : - pour une opération de création ou suppression, le contexte parent récupère la modification. - pour une opération de modification, le contexte parent ne récupère pas la modification. Avec l'arbre des contextes suivants : RootTopiaContext + | ctxt | subCtxt A partir de subCtxt, je fais un entity.update() puis subCtxt.commitTransaction(); A partir de ctxt, je recharge entity à partir du dao et je ne récupère pas la modification. J'ai effectué des tests dans ObServe, je vais les ajouter dans ToPIA-persistence. Je ne vois pas la raison pourquoi cette différence de comportement apparaît ? Si personne n'a d'explication je ferais un rapport de bug dans ToPIA. Tony.

2 3

Migration SVN topia
by Arnaud Thimel Sept. 21, 2008

Sept. 21, 2008

Bonjour, La structure du SVN de topia a été réorganisée. Pour mettre à jour votre copie locale, voici la commande à effectuer (dans le dossier racine de topia2, là où est le pom.xml) : svn switch svn+ssh://NOM_DU_DEVELOPPEUR@labs.libre-entreprise.org/svnroot/topia/topia/trunk (Pensez à remplacer NOM_DU_DEVELOPPEUR par votre userId) La marche à suivre est la même pour topia-service, maven-topia-plugin. A noter simplement que topia2 n'existe plus en tant que 'topia2', il est remplacé par 'topia' en version 2 ! topia1 en devenu une branche de topia nommée 'topia1-trunk' disponible ici : svn+ssh://NOM_DU_DEVELOPPEUR@labs.libre-entreprise.org/svnroot/topia/topia/branches/topia1-trunk @+ Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28

2 2

Re: [Topia-devel] [Topia-commits] r1045 - trunk/topia2
by Benjamin POUSSIN Aug. 27, 2008

Aug. 27, 2008

On Tue, 26 Aug 2008 23:34:43 +0200 (CEST) tchemit(a)users.labs.libre-entreprise.org wrote: > pour le moment, je ne suis pas convaincu de processer les fichiers java vers un repertoire que maven inclut dans le cp ? dans les ide, on se retrouve alors des duplicated classes. > > Ma question : doit-on processer topia ? Oui, il le faut absolument sinon on a des templates non processe, et donc non utilisable car tout le code de generation est en commentaire :( -- 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

héritage multiple vers JAVA
by Eduardo Oré Herrera May 29, 2008

May 29, 2008

J'ai remarqué que l'héritage multiple est permis dans LutinGenerator, mais pas géré par JAVA, ce qui pose un problème lors de la création des DTO par les templates de TOPIA. L'héritage multiple n'est pas géré par JAVA, cependant lorsqu'on modélise un cas d'héritage multiple avec ArgoUML, il n'y aucun avertissement sur ce problème. TOPIA ne devrait pas générer lors de l'utilisation de l'héritage multiple vers les langages qui ne le supportent pas. Cordialement, Eduardo

3 2

[Fwd: [Topia-cvscommit] [topia2] src/java/org/codelutin/topia/generator]
by Arnaud Thimel Nov. 22, 2007

Nov. 22, 2007

Eric, es-tu bien sur de ce que tu as fait là ? : ... -/*{ <bag name="<%=getName(attr)%>" <%=orderBy%> <%=((!isInverse)?"":"inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="true"> +/*{ <bag name="<%=getName(attr)%>" <%=orderBy%> <%=((isInverse)?"":"inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="true"> <key column="<%=GeneratorUtil.getReverseDBName(attr)%>"/> <one-to-many class="<%=getType(attr)%>" node="topiaId" embed-xml="false"/> </bag> }*/ }else { -/*{ <list name="<%=getName(attr)%>"<%=((!isInverse)?"":" inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="false"> +/*{ <list name="<%=getName(attr)%>"<%=((isInverse)?"":" inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="false"> ... -------- Message original -------- Sujet: [Topia-cvscommit] [topia2] src/java/org/codelutin/topia/generator Date: Fri, 16 Nov 2007 15:01:54 +0100 (CET) De: chatellier(a)users.labs.libre-entreprise.org Pour :: topia-cvscommit(a)lists.labs.libre-entreprise.org Changement dans le répertoire topia2/src/java/org/codelutin/topia/generator: --- lazy = true par defaut si pas de lazy defini --- (par chatellier) Fichiers affectés: ------------------ EntityHibernateMappingGenerator.java modifié (1.39 -> 1.40) -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28 Index: topia2/src/java/org/codelutin/topia/generator/EntityHibernateMappingGenerator.java diff -u topia2/src/java/org/codelutin/topia/generator/EntityHibernateMappingGenerator.java:1.39 topia2/src/java/org/codelutin/topia/generator/EntityHibernateMappingGenerator.java:1.40 --- topia2/src/java/org/codelutin/topia/generator/EntityHibernateMappingGenerator.java:1.39 Wed Nov 14 23:01:16 2007 +++ topia2/src/java/org/codelutin/topia/generator/EntityHibernateMappingGenerator.java Fri Nov 16 14:01:49 2007 @@ -24,10 +24,10 @@ * Created: 12 déc. 2005 * * @author Arnaud Thimel <thimel(a)codelutin.com> -* @version $Revision: 1.39 $ +* @version $Revision: 1.40 $ * -* Mise a jour: $Date: 2007-11-14 23:01:16 $ -* par : $Author: thimel $ +* Mise a jour: $Date: 2007-11-16 14:01:49 $ +* par : $Author: chatellier $ */ package org.codelutin.topia.generator; @@ -328,16 +328,19 @@ if (attr.getTagValue("lazy") != null){ lazy += attr.getTagValue("lazy"); } + else { + lazy += "true"; + } lazy += "\""; if (!isIndexed) { -/*{ <bag name="<%=getName(attr)%>" <%=orderBy%> <%=((!isInverse)?"":"inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="true"> +/*{ <bag name="<%=getName(attr)%>" <%=orderBy%> <%=((isInverse)?"":"inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="true"> <key column="<%=GeneratorUtil.getReverseDBName(attr)%>"/> <one-to-many class="<%=getType(attr)%>" node="topiaId" embed-xml="false"/> </bag> }*/ }else { -/*{ <list name="<%=getName(attr)%>"<%=((!isInverse)?"":" inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="false"> +/*{ <list name="<%=getName(attr)%>"<%=((isInverse)?"":" inverse=\"true\"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="false"> <key column="<%=GeneratorUtil.getReverseDBName(attr)%>"/> <index/> <one-to-many class="<%=getType(attr)%>" node="topiaId" embed-xml="false"/> @@ -406,6 +409,9 @@ if (attr.getTagValue("lazy") != null){ lazy += attr.getTagValue("lazy"); } + else { + lazy += "true"; + } lazy += "\""; /*{ <<%=(isIndexed?"list":"bag")%> name="<%=getName(attr)%>" table="<%=GeneratorUtil.getManyToManyTableName(attr)%>" <%=(isInverse?"inverse=\"true\" ":"")%> <%=lazy%> <%=cascade%> node="<%=getName(attr)%>" embed-xml="true"> _______________________________________________ Topia-cvscommit mailing list Topia-cvscommit(a)lists.labs.libre-entreprise.org https://lists.labs.libre-entreprise.org/mailman/listinfo/topia-cvscommit

2 2

[Migration] Calcul des dépendances
by Eric Chatellier Nov. 2, 2007

Nov. 2, 2007

Salut, Je travaille sur le modèle de isis-fish, et effectivement il ne contient pas de boucle. Par contre, les mapping hibernate issue de la génération semblent en contenir. Pour la migration du schema, on s'était basé sur le parcourt des mappings hibernate pour calculer les dépendances des entités entre elles et ainsi definir un ordre de migration. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping default-access="field" auto-import="true" package="fr.ifremer.isisfish.entities"> <union-subclass name="fr.ifremer.isisfish.entities.MetierSeasonInfoImpl" extends="fr.ifremer.isisfish.entities.SeasonImpl" table="metierSeasonInfo" node="fr.ifremer.isisfish.entities.MetierSeasonInfoImpl" abstract="false" proxy="fr.ifremer.isisfish.entities.MetierSeasonInfo" >  <property name="seasonZoneComment" type="text" access="field" column="seasonZoneComment" node="seasonZoneComment"/> <property name="comment" type="text" access="field" column="comment" node="comment"/> <bag name="speciesTargetSpecies" lazy="true" cascade="all,delete-orphan" node="speciesTargetSpecies" embed-xml="true"> <key column="metierSeasonInfo"/> <one-to-many class="fr.ifremer.isisfish.entities.TargetSpeciesImpl" node="topiaId" embed-xml="false"/> </bag> <many-to-one name="metier" class="fr.ifremer.isisfish.entities.MetierImpl" column="metier" node="metier/@topiaId" embed-xml="false"/> <bag name="zone" table="metierseasoninfo_zone" lazy="true" node="zone" embed-xml="true"> <key column="metierSeasonInfo"/> <many-to-many class="fr.ifremer.isisfish.entities.ZoneImpl" column="zone" node="topiaId"/> </bag> </union-subclass> </hibernate-mapping> Par exemple: <many-to-one name="metier" class="fr.ifremer.isisfish.entities.MetierImpl" column="metier" node="metier/@topiaId" embed-xml="false"/> defini une dependance mais n'est pas utilisé parce que non "navigable" de ce coté. (celle-ci j'ai essayé de l'enlever ca ne pose pas de problème) Par contre, celle ci <bag name="speciesTargetSpecies" lazy="true" cascade="all,delete-orphan" node="speciesTargetSpecies" embed-xml="true"> <key column="metierSeasonInfo"/> <one-to-many class="fr.ifremer.isisfish.entities.TargetSpeciesImpl" node="topiaId" embed-xml="false"/> </bag> devrait ^tre supprimée, mais je pense qu'elle est utile pour la suppression en cascade... Voilà le problème :), je ne sais pas si on peut avoir un mapping sans boucle, et que cela fonctionne correctement. Ou alors s'il est possible de savoir si une relation n'ai pas une vraie dépendance... Eric

1 0