Discussion :

[onlytoine]

Hello,

J'ai besoin de mémoriser un état pour un n-uplet. J'ai donc actuellement quelque chose comme ça par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
MonNUplet nuplet = new MonNUplet(val1, val2, val3, ...);
 
Map saved = new HashMap();
 
saved.put(nuplet, Boolean.TRUE);

Le problème est que pour faire une recherche, je suis obligé de reconstruire mon nuplet. Et j'ai bcp d'insertion et de test à faire dans ma Map.

Je cherche donc un moyen de générer quelquechose à partir de val1, val2, val3, ... permettant une insertion et une recherche plus rapide.

Merci!

Toine


[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

[mimil]

D'apres ce que j'ai cru comprendre, tu as un probleme de persistance des données n'est ce pas ? Et bien tu n'est pas le seul et plusieurs framwork existent pour remedier a cela et au passage permettre la genericite des BDD, la manipulation d'objets a la place de tuples, le mapping par xml, enfin bref tout ce dont tu peux rever ^^. Le plus connu et probablement le plus abouti est Hibernate.(hibernate.org).

[onlytoine]

heu non pas de problème de persistance ...

Juste une problématique de stockage et recherche dans une Map

Merci qd même

Toine

[NGY]

Tu peux détailler un peu plus ton problème ?
Je ne suis pas sûr de tout bien comprendre.

[lunatix]

perso je ferais un objet custom de Type MonNtuplet qui va contenir le ntuplet habituel et le boolean.

[mimil]

Expliques moi mieux ton probleme (suis dur du compreunoir meuoi ^^), à un moment tu te retrouves a sortir un nouveau tuple de la base et tu dois le comparer a ceux de ta hastable pour voir si il est a true c'est bien ca ? Donc ce qui te pause probleme c'est de devoir instancier le tuple pour faire un equals avec la ref du hastable c'est ca ?

Suis un garcon perseverant meuoi ^^.

[onlytoine]

Donc ce qui te pause probleme c'est de devoir instancier le tuple pour faire un equals avec la ref du hastable c'est ca ?

vala

je vais devoir instancier bcp de tuples pour faire des recherches ... Je trouve ça dommage, je cherche une parade !

Toine

[divxdede]

Ce que je ne comprends pas c'est que si tu veux faire une recherche pour un tuple en particulier c'est que tu "connais" ce tuple et donc que tu le possèdes à priori ?

[onlytoine]

Oui je le connais... J'ai une méthode qui me demande "as tu déjà traité le nuplet val1, val2, val3 ?"

Pour le savoir, je construis un nuplet avec va1, val2 et val3 et je regarde dans ma map s'il il s'y trouve ...

Toine

[fabszn]

perso je ferais un objet custom de Type MonNtuplet qui va contenir le ntuplet habituel et le boolean.

Hello,

Je suis d'accord avec Lunatix..
ce custom Type porterai la responsabilité de son etat. Je trouve que ce serai mieux de laisser ca à une hashtable!

Les valeurs representant le Ntuple viennent d'ou?

[REEDITION]

Tu peux utiliser un objet Set en utilisant la methode contains(Object) boolean

Pour faire utiliser contains, il faut que implement les methodes hashcode() et equals().

et plus besoin de champ boolean !

[mimil]

Je suis d'accord avec Lunatix..
ce custom Type porterai la responsabilité de son etat. Je trouve que ce serai mieux de laisser ca à une hashtable!

Moi je suis daccord aussi mais cela ne va pas resoudre son probleme puisqu'il doit reextraire l'objet de sa table et le comparer a ceux de sa hashmap si jai bien compris mais il ne m'a pas dementi alors.
Neanmoins moi je garderais cette idee mais egalement ta Hashmap sauf que comme clé dans ma hashmap je mettrais la clé primaire de mon tuple ce qui evite le parcours de ta hashmap en faisant un equals sur chaque objet (si c bien ce que tu faisais). Et cela tevitera peut etre aussi d'instancier ton objet si tu peux ne recuperer que la clé de l'objet lors de ton acces BDD. Apres cela depend de ton architecture.
Enfin si tu veux que ce soit encore plus performant tu mets carrement ton booleen dans ton tuple en BDD puis ca sera plus simple mais bon surement moins propre.

[phlip]

Je ne sais pas quelle valeurs peuvent prendre val1, val2 ... mais pourquoi ne pas remplacer ta classe n-uplet pas une String qui serait la concaténation de toutes tes valeurs.

La première fois que tu crées ta String, tu crées une entrée dans la table des Strings que gère la JVM. Ensuite, toute autre String de même valeur fait référence à cette première entrée, et tu ne crées donc pas de nouvel objet.

Lors de tes recherches, tu peux alors créer la clef recherchée par des concaténations dans une instance StringBuffer, ce qui évite de créer des String intermédiaires. Tu peux ensuite rechercher ton booléen dans la Map mais en utilisant comme clef la String donnée par toString( ) du StringBuffer.

Tout ça peut être assez rapide si tu as des valeurs val1, val2 ... etc pas trop longue ni trop nombreuses pour ne pas avoir des Strings de plusieurs kilomètres.