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

[ANN] - ToPIA 2.3.0-beta-7 released
by nuiton.org Release Notification 31 Jan '10

31 Jan '10

1 0

[ANN] - ToPIA 2.3.0-beta-6 released
by nuiton.org Release Notification 26 Jan '10

26 Jan '10

1 0

[ANN] - ToPIA 2.3.0-beta-5 released
by nuiton.org Release Notification 20 Jan '10

20 Jan '10

1 0

Retour sur Ano #235 : Problème sur les index
by Florian Desbois 19 Jan '10

19 Jan '10

Bonjour à tous, J'aurais aimé quelques retours sur cette demande : http://www.nuiton.org/issues/show/235 Il y un problème à creuser autour des index et de la prise en charge dans hibernate. De même, la cohérence entre EUGene et ToPIA sur le 'Unique'. Qu'en pensez-vous ? Cordialement, Florian

1 0

[ANN] - ToPIA 2.3.0-beta-4 released
by nuiton.org Release Notification 17 Jan '10

17 Jan '10

1 0

[ANN] - ToPIA 2.3.0-beta-3 released
by nuiton.org Release Notification 06 Jan '10

06 Jan '10

The ToPIA team is pleased to announce the topia-2.3.0-beta-3 release! Tools for Portable and Independent Architecture : Framework de persistance et de distribution d'application. No changes defined in this version : see roadmap for 2.3.0 version on http://nuiton.org/versions/show/41 For a manual installation, you can download files here: http://www.nuiton.org/projects/list_files/topia Have fun! -ToPIA team

1 0

TopiaCreateDate
by Florian Desbois 06 Jan '10

06 Jan '10

Bonjour à tous, Le topiaCreateDate est désormais devenu un timestamp sur la version SNAPSHOT du trunk (2.3.0) : http://nuiton.org/issues/show/177 Le mapping hibernate a donc changé pour cette attribut, peut être cela va t'il influencer les migrations des bases ? A voir avec Topia-Migration. Cordialement, Florian

4 7

Changement version modele pour TopiaSecurity et TopiaHistory
by Florian Desbois 06 Jan '10

06 Jan '10

Bonjour, La demande #177 : http://nuiton.org/issues/show/177 concernant le changement du format de topiaCreateDate de date à timestamp a provoqué le changement de version des modèles de TopiaSecurity et TopiaHistory qui passent de 1 à 1.1. Voir r1748 : http://nuiton.org/repositories/revision/topia/1748 Cordialement, L'équipe de dev ToPIA

1 0

Utilisation HQL pour manipulation des collections : fonction elements()
by Florian Desbois 06 Jan '10

06 Jan '10

Bonjour à tous, J'ai trouvé un moyen très puissant de manipuler les collections en HQL, la fonction elements() qui simplifie grandement les problèmes de relation N-N. Prenons un exemple : ----- * * ----- | A |<---------->| B | ----- ----- Clairement aucune entité n'est généré comme classe association dans ce cas. Dans la génération ToPIA une requête SQL est utilisé pour la suppression, par exemple d'un élément B dans tous les A qui le contienne. Cela donne : getContext().getHibernate().createSQLQuery( "SELECT main.topiaid " + "from A main, A_B secondary " + "where main.topiaid=secondary.fishingZone" + " and secondary.sampleRow='" + entity.getTopiaId() + "'") .addEntity("main", TopiaDAOHelper.getImplementationClass(A.class)).list(); Ce qui est fastidieux et rend fortement la génération dépendante d'Hibernate. Ce code est remplacable par : getContext().find("SELECT main FROM A main, B secondary WHERE secondary IN elements(B.A) AND A.topiaId = :topiaId", "topiaId", entity.getTopiaId()); De la même manière les méthodes findContains sont refactorables en utilisant cette fonction HQL, plutôt qu'un for sur un findAll. Plus d'info : http://docs.jboss.org/hibernate/core/3.3/reference/fr/html/queryhql.html#qu… Cordialement, Florian

1 1

Souci de perf + TopiaQuery
by Florian Desbois 05 Jan '10

05 Jan '10

Bonjour à tous, Voilà, j'ai constaté que les méthodes findBy des DAO prenaient beaucoup de temps à l'exécution et augmentait au fur et a mesure. Sur un algorithme d'import d'un fichier contenant 85000 lignes, il est impensable d'avoir un temps qui augmente au fur et a mesure de l'appel au findBy. Pour m'en rendre compte, j'ai remplacé le findBy par une simple requête SQL (ou HQL ca marche aussi) avec Hibernate, et le temps d'exécution est instantané (grâce a un index sur la base) et n'augmente plus du tout dans le temps. Il y a donc un réel souci sur l'utilisation des Criteria d'Hibernate dans ToPIA. En parallèle j'ai travaillé sur une classe pour facilement construire une requête HQL (voir : http://nuiton.org/issues/show/178 ). Cette classe (TopiaQuery) est vraiment simple d'utilisation et permet de créer différentes requêtes plus ou moins complexe et d'interpréter précisément les résultats (type de retour). En essayant de remplacer toutes les utilisations des Criteria par cette classe, le temps d'exécution a fortement diminué, notamment sur une grosse exécution comme décrite plus haut. Alors l'idée, est-ce que ça vous convient de remplacer les criteria par l'utilisation de TopiaQuery ? A l'heure actuelle une version beta de TopiaQuery est sur le trunk. Elle a été légèrement modifié pour être plus souple au niveau des generic (notamment pour les retours au moment de l'exécution de la requête). Donc voilà, j'espère ne pas avoir été trop long, mais qu'en pensez-vous ? Cordialement, Florian

6 8