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

Migration de ToPIA-service vers ToPIA
by Tony Chemit 29 May '09

29 May '09

Yo, J'ai terminée la migration de ToPIA service. 1) les nouveaux modules de ToPIA On a donc maintenant un module par service : topia-service-index topia-service-migration topia-service-security topia-service-history 2) Le modèle xmi J'ai du exploser le modèle xmi vers chaque module (pour security et history) On ne pouvait donc pas garder le même nom de modèle (sinon on se retrouve avec un TopiaServiceDAOHelper dupliqué...) Donc je les ai nommé TopiaSecurity et TopiaHistory. Pour le modèle de test, c'est TopiaServiceTest (pour le moment chaque module possède son modèle de test mais on pourrait peut-être en avoir un unique dans topia-persistence et on expose le module topia-persistence en test-jar :) 3) L'historique svn Il ne peut pas y en avoir... C'est dommage mais il n'est pas possible de faire des copies entre des dépôts svn différents. Je recopie quand même les tags ou niveau de ToPIA en le renommant en topia-service-xxx. Bon week-end, Tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

Probleme : dao.commitTransaction()
by Florian DESBOIS 28 May '09

28 May '09

Salut à tous, Je me retrouve avec un petit souci sur le commitTransaction des DAO. En fait il ne fonctionne pas du tout, il ne se passe rien en Base ! J'ai regardé le code et j'ai constaté dans TopiaDAOAbstract : /** * Par defaut ne fait rien */ public void commitTransaction() throws TopiaException { } /** * Par defaut ne fait rien */ public void rollbackTransaction() throws TopiaException { } Les DAO générés n'étendent pas TopiaDAOAbstract mais TopiaDAODelegator qui lui implémente ces deux méthodes : public void commitTransaction() throws TopiaException { getParentDAO().commitTransaction(); } public void rollbackTransaction() throws TopiaException { getParentDAO().rollbackTransaction(); } Il fait appel au parentDAO pour faire le commitTransaction(). Le parentDAO est initialisé au moment de la récupération du DAO, cad via la methode getMonDAO du ModelHelperDAO généré par ToPIA. Cette méthode appel le getDAO de TopiaContextImpl qui cherche le bon DAO et lui set comment parent un TopiaDAOHibernate par défaut. TopiaDAOHibernate extends TopiaDAOAbstract et n'implémente pas les deux méthodes concernés ! Donc le commitTransaction() fait au départ ne fait rien. Une autre classe extends TopiaDAOAbstract, il s'agit de TopiaDAOFlatfile qui elle, implémente les deux méthodes (vides comme dans le Abstract). Donc normalement rien n'empêcherait de remplir ces deux méthodes directement dans TopiaDAOAbstract ! simplement avec context.commitTransaction() ? Cela peut poser des problèmes si d'autres classes héritent de TopiaDAOAbstract... Que faire donc ? Que pensez vous de ce problème ? Flo

4 9

Implementation utilisateur des DAO
by Florian DESBOIS 28 May '09

28 May '09

Bonjour à tous, D'après ce que j'ai vu dans le code de ToPIA-persistence, il n'y a pas de possibilité que l'utilisateur crée un DAOImpl personnalisé pour remplacer celui généré. En effet le DAOImpl est toujours généré donc incompatibilité si l'utilisateur en crée un nouveau et aucune prise en compte car l'interface (faux, voir plus loin) n'est pas mise à jour avec les nouvelles méthodes. A l'instar des Entités, il serait intéressant de pouvoir rajouté dans le modèle XMI la possibilité d'ajouter des méthodes sur les DAO et non sur les Entités. Pourquoi ? Tout simplement pour permettre l'ajout de méthode spécifique au DAO non généré (recherche complexe, autre traitement non pris en compte avec utilisation du SQL avec Hibernate (je sais plus le nom du langage) pour une requête complexe, ...). Je propose donc la prise en compte de ces méthodes en les signalant comme "static" au niveau des entités. La logique suit, une méthode static est bien général à l'ensemble des entités donc dans un DAO. Je viens de voir que les DAO n'ont pas le même modèle de génération que les entités à savoir : une interface, une classe abstraite, une classe implémentation mais une classe abstraite, une classe implémentation et une classe finale qui hérite de l'implémentation et est utilisé dans les Helper (donc par l'utilisateur). Pourquoi cette différence ? Du coup les changements serait a apporté normalement dans le DAOImplGenerator qui ne doit pas généré le DAOImpl si l'entité lié possède une méthode abstraite. Il serait intéressant pour globaliser cette notion de rajouter une méthode hasAbstractOperations dans ObjectModelClass de EUGene. Je m'égare peut-être, il y a peut-être déjà une autre possibilité d'étendre les DAO ? Sinon, qu'en pensez vous de pouvoir préciser des méthodes static dans les entités qui seront à implémenter par l'utilisateur dans les DAO (les méthodes ne seront pas static donc) ? J'espère avoir été clair et précis :p Florian

4 7

hashCode dans TopiaEntityAbstract
by Tony Chemit 06 May '09

06 May '09

Salut les lutins, Dans TopiaEntityAbstract, le code de la méthode hashCode me parrait un peu étrange. /** * On utilise la date de creation comme hash code, cette date ne varie pas * au cours du temps */ @Override public int hashCode() { int result = getTopiaCreateDate().hashCode(); return result; } Cela transgresse l'ordre naturel des entités. On devrait toujours avoir a.equals(b) ==> a.hashCode() == b.hashCode() J'ai un validateur dans Jaxx qui utilise les hashCodes de proprietes d'une entite pour construire une empreinte de clef unique (et manque de bol une des propriété est une autre entités,...); vu le code dans TopiaEntityAbstract ça ne peut pas marcher. Dans la javadoc de Sun, il est préciser que modifier l'idiom entre la méthode equals et hashCode doit être justifié. Je n'ai pas vu de doc là-dessus dans ToPIA :) Y'a-t-il une raison précise pour utiliser la date de creation comme hashCode ? Est-ce qu'on pourrait changer ça en deportant le calcul du hashCode sur celui du topiaId : @Override public int hashCode() { int hash = 97 * 7; if (topiaId != null) { hash += topiaId.hashCode(); } return hash; } Tony

3 11

Soucis de perf sur TopiaContext.restore()
by Eric Chatellier 30 Apr '09

30 Apr '09

Bonjour, Je retranscrit une conversation concernant un soucis de performance (voire de memory leak) sur TopiaContext.restore(). Le principal soucis est qu'a leur actuellement, l'ouverture d'un TopiaContext fait énormément de chose dont on a pas réellement toujours besoin : - chargement des mappings (xml) - migration de base de donnée (dans les services) + seconde lecture des mappings (xml) Le restore consiste a injecter un script SQL, on a pas besoin de charger la machine hibernate pour ça. Donc un début de solution, consistait a ajouter une méthode permettant d'injecter un dump directement via H2. Donc une méthode statique restore(Properties config, File sqlFile); qui appelera restore(String jdbcURL, File sqlFile); org.h2.tools.RunScript.main("-url jdbc:h2:~/test", "-script test.sql", "-options compression gzip"); On pourrait aussi gérer d'autre format h2 (zip, lzf...) -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 0

Flush manual ou pas
by Benjamin POUSSIN 10 Apr '09

10 Apr '09

public TopiaContext beginTransaction() throws TopiaException { checkClosed("Ce contexte a ete ferme, impossible de commencer une transaction"); TopiaContextImpl result = new TopiaContextImpl(this); SessionFactory factory = getHibernateFactory(); result.hibernate = factory.openSession(); // new TopiaInterceptor(result)); // on ne synchronise jamais les données avec la base tant que // l'utilisateur n'a pas fait de commit du context result.hibernate.setFlushMode(FlushMode.MANUAL); On a toujours ca qui traine dans le code, il faudrait tout de meme voir s'il y encore un interet (faire des tests en enlevant et voir si tout fonctionne pareil) (voir peut-etre mieux ?) Normalement, c'etait la pour faire des sous-sous-...-sous-context. mais comme ca ne semble pas fonctionner. Et moitier aussi servir pour prendre en compte des problemes dans certaine base qui gerait mal les transactions, mais je pense que H2/Postgresql sont maintenant assez bien faite pour bien cloisonner les transactions. qui aurait un peu de temps pour regarder le probleme de plus pret ? (c-a-d, quelqu'un aurait-il deja un jeu de test sur lequel regarder rapidement ?) -- 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

Re: [Topia-devel] [ToPIA-persistence] Nouvelle Modif
by Florian DESBOIS 07 Apr '09

07 Apr '09

Ok c'est fait Cette maj de ToPIA est directement utilisable dans mon projet Chorem maintenant ?

2 1

[ToPIA-persistence] Nouvelle Modif
by Florian DESBOIS 07 Apr '09

07 Apr '09

Bonjour à tous, Pour contribuer à ToPIA et ajouter une nouvelle modif dont j'ai fais la "feature request", je modifie et commit directement sur le trunk ? Il s'agit d'ajouter des variables statiques dans les interfaces des entités correspondants aux noms des champs. Ainsi l'utilisation des properties avec les DAO (findByProperties) sera simplifié : complétion possible + compilation pour vérification de l'existence du champ. Exemple : public interface Product extends TopiaEntity { public static final String NAME = "name"; public static final String TYPE = "type"; ... } Utilisation : ProductDAO productDAO = ModelDAOHelper.getProductDAO(context); Product product = productDAO.findByProperties(Product.NAME,"Mug",Product.TYPE,"Ustensile de cuisine"); Je pense que c'est un bon emplacement. A voir, si vous êtes de mon avis (peut-être à placer dans les DAO, dans le Abstract ?? ??) Cordialement, Florian

2 1

Re: [Topia-devel] [Topia-commits] r1403 - topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator
by tony Chemit 18 Mar '09

18 Mar '09

On Tue, 17 Mar 2009 15:30:41 +0100 (CET) chatellier(a)users.labs.libre-entreprise.org wrote: > Author: chatellier > Date: 2009-03-17 14:30:41 +0000 (Tue, 17 Mar 2009) > New Revision: 1403 > > Modified: > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/TopiaGeneratorUtil.java > Log: > Replacement de orderBy par "order-by" (cf isis) > > Modified: > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/TopiaGeneratorUtil.java > =================================================================== > --- > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/TopiaGeneratorUtil.java > 2009-03-02 10:09:53 UTC (rev 1402) +++ > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/TopiaGeneratorUtil.java > 2009-03-17 14:30:41 UTC (rev 1403) @@ -118,7 +118,7 @@ public static > final String TAG_FETCH = "fetch"; /** Tag pour spécifier la caractère > order-by d'une association multiple */ > - public static final String TAG_ORDER_BY = "orderBy"; > + public static final String TAG_ORDER_BY = "order-by"; > J'avais fais cette modification car cela ne fonctionnait pas avec order-by ? et maintenant ça remarche ? > /** Tag pour spécifier la caractère not-null d'un attribut */ > public static final String TAG_NOT_NULL = "notNull"; > > _______________________________________________ > Topia-commits mailing list > Topia-commits(a)lists.labs.libre-entreprise.org > https://lists.labs.libre-entreprise.org/mailman/listinfo/topia-commits

2 3

Re: [Topia-devel] [Topia-user] Fw: topia-contexte hibernate exception
by Éric Chatellier 02 Mar '09

02 Mar '09

Erwan Nema a écrit : > Bonjour Bonjour, > merci à tous les 2 , la persistence de nos entités fonctionne maintenant. ok > pour infos > j'ai 2 zargos dans le répertoire xmi : > -pollen.zargo avec le modèle pollenModel contenant les classes > entities avec stéréotype (package > org.codelutin.pollen.business.persistence) > -pollenDTO.zargo avec le modèle dtoModel contenant les classes dtos > (pas de package, pas de stéréotype ) Si vous voulez générer ce modele en DTO, il faut que les classes soient stéréotypeées "dto". ToPIA ne génére rien s'il n'y a pas de stéréotype. Et il vaut mieux mettre un package, sinon cela sera également généré hors package. > Topia m'a généré toutes les classes entities dans le bon package mais > mes classes helpers s'appellent DTOModelDAOhelper, DTOModelEntityEnum, > DTOModelEntityProvider > alors que je m'attendais à PollenModelDAOHelper,... > (le zargo DTO a été chargé après le zargo pollen) ToPIA utilise le nom de modèle défini dans ArgoUML. Je pense que actuellement ce nom est "DTOModel". > > Erwan Nema -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 0