Problème d'index pour un array

Bonjour,

J'ai un problème avec hibernate et le fichier de mapping.
Dans mon .hbm je défini un array et je suis donc obligé de définir un index
exemple :

Code:

---

1 2 3 4 5

<array name="children" lazy="true" inverse="true"> <key column="parent_id"/> <index column="index_col"/> <one-to-many class="net.sf.test.Child"/> </array>

---

Je voudrais pouvoir ne pas utiliser ces index, ceci me rajoute une colonne index_col dans ma table, c'est un peu lourd.

Je ne peux pas utiliser des set car je n'arrive pas à récupérer toutes mes données avec ceci, de plus les tableaux sont plus pratiques pour ma partie client à gérer.

Si quelqu'un a une solution pour ne pas utiliser ces index ??

Merci

Y a pas beaucoup de choix, soit t'as un index (utilisable avec arrays, list et map), soit t'en a pas et il te faut utiliser un Set ou un Bag (les données n'ont pas d'ordre spécifique).

Si t'arrive pas a récupérer toutes tes données sans index, c'est que t'as des duplicatas et que l'index est le seul moyen de faire la différence. (dans ton cas, un parent aurais deux fois le même enfant)

Je trouve ca très lourd de devoir rajouter une colonne dans la BD pour ordonner les elements.

Je ne peu pas utiliser les set, les bag je n'est pas tester mais je ne pense plus avoir le temps de changer cela.
Je voudrais simplement manipuler un array avec le moins d'impact possible sur la base de données.

Un autre problème inhérents a ces index :

J'ai une table année et une table parcours, entre les 2 tables j'ai une table r_année_parcours qui regroupe les id de parcours et année. Pour avoir la liste des parcours d'une &nnée et la liste des années pour un parcours j'ai 2 tableau dans les 2 sens.

Dans ma table r_annee_parcours j'ai donc : an_id,par_id,an_idx,par_idx . Le problème c'est que quand j'ajoute une année et un parcours il me rajoute automatiquement le an_idx mais ne connait pas le par_idx.

Si quelqu'un a déjà eu ce genre de problème et qu'il a une solution ?
Le mieux serait de ne pas avoir a manipuler ces indexs en base de données qui complexifie un peu tout et pouvoir en même temps manipuler des array.

Juste comme çà, en supposant qu'effectivement tu n'as pas besoin d'index au niveau DB et que c'est jsute ton architecture de ton application qui fait que tu dois utiliser des tableaux plutot que des Set (par exemple, tu utilise tes object avec JSF qui, au niveau de son Expression Language s'attendant à ce que les collections soient indexables). Tu peux utiliser le shéma suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

private SortedSet<monType> maCollectionHibernate;   ....   protected void setMaCollectionHibernate(SortedSet<monType>){...} protected SortedSet<monType> getMaCollectionHibernate(){...}   public monType[] getMaCollection(){ return getMaCollectionHibernate().asArray() } public void setMaCollection(monType[] maCollection){ getMaCollectionHibernate().clear(); getMaCollectionHibernate().addAll(Arrays.asList(maCollection)); }

---

Tu fais gérer par Hibernate une propriété que les autres clients ne manipulent pas (un Set). Et tu crée des propriétés dérivée (l'array ici) qui n'est pas directement gérer par Hibernate. J'ai utilisé çà tout plein au niveau d'un appli ici, çà marche sans soucis.

Note que j'ai utilisé un SortedSet, çà permet de définir un critère de tri sur la collection (au niveau du mapping) qui te permettra de garantir à chaque load() que l'ordre reste le même. C'est pas obligatoire si ton ordre n'a pas d'importance, mais il faut alors savoir que l'ordre peut changer d'un appelt à l'autre si des éléments ont été ajoutés au Set entre deux.

A mon avis t'as fait ton design avec des ndex sans vraiment comprendre ce que çà impliquerais pour la DB, on utilise ces index uniquement si on veut absolument gérer manuellement au niveau de l'appli, un ordre de position strict pour les éléments.

Merci pour ta réponse,
En fait nous avions déjà implémenter une solution similaire a ce que tu as proposé, apparemment coté client ce la ne fonctionnait toujours pas.
Ils on trouvé une solution de remplacement, je ne sait pas trop laquelle..., mais on a gardé les Set.

Pour répondre sur le fait que j'ai fait des choses sans vraiment comprendre, c'est totalement vrai !! Nous avions un délai de 2 semaines pour faire un projet immense (c'est dans le cadre de mes études). Côté client (GWT) cela fonctionnait mieux avec des array donc nous sommes passé a cette solution. Ensuite nous nous sommes aperçu que cela créé des index qui pouvai poser des problème pour le transfert des données de l'ancienne application à la nouvelle.

C'est pas le plus grave, le plus ennuyeux c'est que hibernate respecte strictement l'index -> tu peux avoir des "trous" dans l'array