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

Pourquoi les getters ne renverraient pas une collection vide ?
by Brendan Le Ny Nov. 24, 2014

Nov. 24, 2014

Actuellement, une propriété avec une multiplicité renvoie une collection null si on appelle le getter, pourquoi ne pas initialiser cette collection en lazy (on le fait bien dans le add) ? Voire même, pourquoi pas interdire d'appeler le setter avec null (sauf si Hibernate l'impose) ? Il me semblait y avoir une raison mais elle ne me revient plus. -- Brendan Le Ny, Code Lutin bleny(a)codelutin.com (+33) 02 40 50 29 28

4 4

Méthodes protégées dans AbstractTopiaDao
by Tony Chemit Dec. 19, 2013

Dec. 19, 2013

Hello, Ça me gène un peu d'avoir les méthodes protégées dans l'AbstractTopiaDao. Ok pour qu'elles ne soient pas dans le contrat TopiaDao mais de là à tout mettre en protected, c'est un peu ennuyeux de ne pas laisser la possibilité de les utiliser quand même. Autre question, pourquoi certains forXXX sont publiques et même sur le contrat et d'autre protected ? Exemple forProperties est publique alors que forHql ne l'est pas , y'a rien qui justifie cette différence. Je vous parle de tout ça dans un cas on je ne peux pas récupérer un dao métier et donc... pas même en castant en AbstractTopiaDao je ne peux rien faire... Any idea, avis, else ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit(a)codelutin.com twitter: https://twitter.com/tchemit

2 1

Unicité du topiaId entre deux bases de données
by Eric Chatellier Dec. 13, 2013

Dec. 13, 2013

Bonjour, Dans une application (IsisFish), les utilisateurs dupliquent leur base de données et donc les topiaId sont identiques malgrés le fait qu'il référence deux entités différentes car elle provienent de deux bases différentes. Le problème est que dans l'interface graphique, beaucoup de chose sont basé sur le fonctionnement du equals() qui ne prend en compte que le topiaId. Je me demandais si le equals pourrait dépendre d'autre chose que le seul topiaId. Un peu à la manière des Class java qui ne sont identique que si elle ont été chargées depuis le même class loader. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

3 3

[ANN] - ToPIA 3.0-alpha-7 released
by Arnaud Thimel Dec. 12, 2013

Dec. 12, 2013

The ToPIA team is pleased to announce the topia-3.0-alpha-7 release! Tools for Portable and Independent Architecture : Framework de persistance et de distribution d'application. Documentation of the project can be found here: http://maven-site.nuiton.org/topia Changes ------- Changes in this version include: Fixed Bugs: o fix HqlAndParametersBuilder if a whereClause contains a or Issue: 2959. Thanks to Arnaud Thimel. Resolved by bleny. Changes: o Update Hibernate to 4.2.8.Final Issue: 2957. Thanks to Tony Chemit. Resolved by tchemit. Downloads --------- No release file deployed. (all files are deployed in the maven repository) Maven artifacts --------------- Artifacts are deployed in Maven Central Repository http://repo1.maven.org/maven2/ Find us at * http://search.maven.org/#artifactdetails|org.nuiton|topia|3.0-alpha-7|jar Have fun! -ToPIA team

1 0

Date de modification dans ToPIA
by Arnaud Thimel Dec. 9, 2013

Dec. 9, 2013

Salut, Je me demande si on ne pourrais pas gérer, de façon transparents pour l'utilisateur, les dates de modifications dans ToPIA ? À priori on sait intercepter toute opération de mise à jour avec ToPIA et donc injecter la date courante. Je verrais bien 2 modes différents (configurables) : - technique : toutes les entités ont un champ updateDate qui est mis à jour à chaque sauvegarde (attention, sauvegarde != modification) ; - métier : l'utilisateur ajoute un champ sur son entité (ex: "toto") et dans un tag-value il dit que ce champ doit contenir la date de màj. Le 2ème a surtout pour but de ne pas utiliser un champ technique dans le code métier. Il y a aussi le champ version qu'il faudrait peut-être remettre au goût du jour ? À vos avis. Arnaud

3 2

[ANN] - ToPIA 3.0-alpha-6 released
by Tony Chemit Dec. 3, 2013

Dec. 3, 2013

The ToPIA team is pleased to announce the topia-3.0-alpha-6 release! Tools for Portable and Independent Architecture : Framework de persistance et de distribution d'application. Documentation of the project can be found here: http://maven-site.nuiton.org/topia Changes ------- Changes in this version include: New features: o Rename commitTransaction() and rollbackTransaction() to commit() and rollback() Issue: 2899. Thanks to Brendan Le Ny. Resolved by tchemit. o Maintain a reference between an XxxApplicationContext and its sub-XxxPersistenceContext's Issue: 2922. Thanks to Arnaud Thimel. Resolved by athimel. o Improve Sql APIs Issue: 2926. Thanks to Tony Chemit. Resolved by tchemit. o Make sure AbstractTopiaDao does not rely on TopiaHibernateSupport Issue: 2925. Thanks to Arnaud Thimel. Resolved by athimel. Fixed Bugs: o forXXXIn(Iterable) fail if empty collection is passed Issue: 2953. Thanks to Brendan Le Ny. Resolved by bleny. Changes: o Drop all deprecated code Issue: 2923. Thanks to Arnaud Thimel. Resolved by athimel. o Update to hibernate 4.2.7.SP1 Issue: 2950. Thanks to Éric Chatellier. Resolved by echatellier. Maven artifacts --------------- Artifacts are deployed in Maven Central Repository http://repo1.maven.org/maven2/ Find us at * http://search.maven.org/#artifactdetails|org.nuiton|topia|3.0-alpha-6|jar Have fun! -ToPIA team

1 0

TopiaDao.delete(e) si e.isPersisted() == false ?
by Brendan Le Ny Dec. 3, 2013

Dec. 3, 2013

Si on appelle TopiaDao.delete(e) alors que e.isPersisted() == false ça pète mais ça pète bizarrement. En disant que un object est transient alors qu'il fait un find. J'ai mis deux heures pour comprendre qu'en fait c'est l'objet que j'essaiyais de delete qui était transient :-( Je vous propose au choix : * dans delete(e) : Preconditions.checkArguement(e.isPertisted()) (on pète) mais pour la vraie raison) * dans delete(e) : on englobe tout le code dans if (e.isPertisted()) du coup, si l'objet n'était pas créé, on ne fait rien pour le supprimer. Pour moi, c'est plutôt la première solution. Qu'en pensez-vous ? -- Brendan Le Ny, Code Lutin bleny(a)codelutin.com (+33) 02 40 50 29 28

5 8