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

Petit doute sur le multi rootContext
by Arnaud Thimel 01 Jun '09

01 Jun '09

Salut, Dans une application nous ouvrons plusieurs 'rootContext'. Ils sont différenciés car l'objet Properties utilisé pour la récupération du context varie. Il varie, mais tous les rootContext pointent sur la même base. Est-ce que ça ne peut pas être source à problème ? D'autre part, dans le TopiaContextFactory, j'ai trouvé ça : static public TopiaContext getContext(Properties config) throws TopiaNotFoundException { TopiaContextImpl result = contextCache.get(config); if (result == null || result.isClosed()) { result = new TopiaContextImpl(config); contextCache.put((Properties) config.clone(), result); } } Comme le "equals" de Properties fait un "deep equals", j'ai l'impression que le .clone() ne sert à rien ? Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28

4 5

Sonar desactive pour ToPIA
by Tony Chemit 30 May '09

30 May '09

Hello, Pour info, j'ai désactivé Sonar pour ToPIA car il trouve pas des dépendances sur ToPIA-persistence sur les modules de service (migration) ? Il faudra résoudre ce petit problème. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

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