Discussion :

[Metha_Chemista]

Bonjour,

J'ai crée une application qui permet de créer une interface pour une base de données dans un JTable, et créer et modifier des lignes.

Elles fonctionne de cette façon :

- Au lancement, je remplit la Jtable (via un ResultSet )
- A intervalle régulier, la JTable vérifie si la base a été modifié par un autre utilisateur (à l'aide d'une variable dans la base de données qui s'incrémente dès que l'on modifie la base )
- Si c'est le cas, le JTable refait une requête SQL pour obtenir le ResultSet de la table, ResultSet qui permet de mettre à jour la JTable en changeant ses valeurs (Les valeurs de la JTable sont gérés par une ArrayList, où chaque élément de la liste représente une ligne de la JTable) .

Cependant la mise à jour réinitialise pratiquement en entier la JTable, et j'ai peur que cette mise à jour prenne du temps lorsque la table sera très longue (> 5000 lignes ), et les mises à jour ne concerneront à chaque fois que quelques lignes max.

Je me pose donc la question suivante : Y'a t'il un moyen d'optimiser la mise à jour de la JTable, en ne changeant que les valeurs (ou les lignes) qui ont été modifié ? Est-ce possible ?

Merci d'avance

[joel.drigo]

Salut,

Il est possible de ne mettre à jour que certaines de la JTable, oui. Mais il te faudra un moyen de reconnaitre les lignes (par exemple, un identifiant unique d'enregistrement), d'une, un moyen bien sûr de (re)connaître les lignes modifiées, supprimées, ajoutées, déjà dans la base, puis dans le ResultSet.

Techniquement, il n'est pas possible avec un DefaultTableModel de remplacer une ligne de la JTable en un appel de méthode (il faudra appeler setValueAt() pour chaque colonne). En revanche, tu peux ajouter une ligne, ou en supprimer. Si ajouter une ligne ne pose aucun problème particulier (appel de la méthode addRow()), la suppression se faisant par index et non par valeur d'une colonne (identifiant d'enregistrement), il te faudra un moyen de retrouver cette correspondance, avec une Map par exemple.

Il est donc préférable d'écrire son propre modèle, pour gérer tous ces cas. Tu pourras éventuellement par la suite t'arranger pour que la modification (ajout, suppression modification) soit faite en tâche de fond, pour éviter de bloquer la JTable quelque soit le nombre de modification.

[Metha_Chemista]

Merci pour ta réponse !

En fait je ne l'ai pas vraiment indiqué, mais j'utilise déjà un TableModel personnalisé, et j'utilise aussi les clés créées par la BDD ("primalKey" je crois de mémoire ).

J'ai aussi crée des méthodes addTransport() , removeTransport() et editTransport() pour interagir avec la liste des transports affichées (la JTable gère des transports ^^), et tous les transports contiennent la "key" en attributs.

Pour détailler ma méthode d'actualisation, je fonctionne de la sorte :
- Je récupère le ResultSet contenant ma BDD, puis je parcours les lignes une par une du ResultSet
- Pour chaque ligne je regarde la "key" et je la cherche dans la liste des Transports de la Jtable, j'ai donc différents cas :
1) la JTable ne contient la "key" -> je crée un transport à partir de la ligne du ResultSet et je l'ajoute dans mon TableModel avec addTransport
2) la JTable contient la "key" -> je récupère le transport dans mon TableModel et je l'édite avec editTransport ( editTransport met à jour un par un les attributs du transport )
- Enfin, Les transports restants sont supprimées ( car non présent dans le ResultSet, donc on les supprime de la JTable ).

Voilà je ne sais pas si c'est trop clair, je n 'ai pas le code sous la main

Mon potentiel soucis de temps de calcul va concerner la méthode editTransport, qui sera appelé majoritairement lors de la mise à jour. En effet elle met à jour tous les attributs du transport sans se préoccuper de savoir si la ligne à été modifié dans la BDD.

En gros on met à jour toutes les lignes, sans savoir lesquelles on vraiment été modifié. Mais je ne sais pas justement comment savoir quelles lignes ont été modifié dans la BDD


EDIT : ce n'ai pas "primalKey" mais "identity" pour les ID des transports !

[joel.drigo]

L'important, quand on met à jour le modèle d'une JTable, c'est de soulever les évenements adéquates qui vont faire que la JTable se rafraichit à l'écran (y compris la prise en compte des filtres, tris, etc...). Si tu procèdes à une mise à jour en tâche de fond, qui teste l'égalité entre une ligne du modèle et sa remplaçante lors d'un édit, déjà tu peux éviter de lancer l'évenement en question. Ce n'est pas vraiment l'affectation des valeurs qui va prendre particulièrement du temps, mais surtout l'impact sur l'affichage. Ensuite, prévois bien une map pour accèder plus rapidement à tes lignes en fonction de l'identifiant (pour éviter un scan de toutes les lignes à chaque edit). Essaye également de traiter les évenements en un minimum de fois : ce n'est pas forcément simple sans arriver à une usine à gaz, mais au moins par bloc (par exemple, si plusieurs lignes consécutives sont modifiées, faire fireTableRowsUpdate(first,last) une fois, et non pas un pour chaque ligne).

[Metha_Chemista]

Ah ok, je faisais pas trop gaffe aux événements (J'utilisais fireTableRowUpdated à chaque ligne pratiquement), je vais faire un test d'égalité avant de l'appeler.

Je vais me renseigner aussi sur les maps, je ne sais pas du tout ce que c'est

Merci beaucoup

Pour finir j'ai une petite question : pour faire " transport.equal( transport ) ", il faut redéfinir la méthode "equal" ? Ou bien la fonction la méthode héritée de Object convient - elle?

[joel.drigo]

Pour finir j'ai une petite question : pour faire " transport.equal( transport ) ", il faut redéfinir la méthode "equal" ? Ou bien la fonction la méthode héritée de Object convient - elle?

Si, bien sûr qu'il faut redéfinir equals().

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
public class Transport {
 
   private final String nom;
 
   public Transport(String nom) {
        this.nom=nom;
   }
 
   public String getNom() {
         return nom;
   }
 
   public static void main(String[] args) {
 
	   Transport transport1 = new Transport("Train");
	   Transport transport2 = new Transport("Train");
 
	   System.out.println(transport1.equals(transport2));
 
   }
 
}

Affiche

false

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class Transport {
 
   private final String nom;
 
   public Transport(String nom) {
        this.nom=nom;
   }
 
   public String getNom() {
         return nom;
   }
 
   @Override
	public boolean equals(Object obj) {
	   	if ( obj instanceof Transport ) {
	   		return Objects.equals(((Transport)obj).nom,nom);
	   	}
		return super.equals(obj);
	}
 
   public static void main(String[] args) {
 
	   Transport transport1 = new Transport("Train");
	   Transport transport2 = new Transport("Train");
 
	   System.out.println(transport1.equals(transport2));
 
   }
 
}

Affiche bien

true

ce qui va te permettre de comparer l'ancienne ligne et la nouvelle de remplacement (sinon, il faudrait faire une égalité externe entre chaque propriété, genre if ( Objects.equals(transport1.getNom(), transport2.getNom()) { }

[Metha_Chemista]

Ok très bien je vais redéfinir "equal" alors (je voulais être sûr, mon objet transport a plus de 30 attributs ^^).

J'ai aussi pensé a une méthode pour identifier les lignes modifiés :

On rajoute dans la BDD une colonne "VERSION" (int), qui va symboliser la version de chaque ligne.
Ainsi dès que l'on crée une ligne, on initialise la version à 0 dans le BDD, et chaque modification de cette ligne incrémente la version.

De plus pour ma JTable, je rajoute également un attribut "version" pour mes transports. Ces attributs s'initialiseront lors de la création de la JTable.

Donc au moment de la mise à jour je pourrais comparer les versions BDD/JTable au lieu de comparer les transports avec "equal".

Merci beaucoup

[joel.drigo]

Dans ce cas, il vaudrait mieux comparer que l'attribut "version", mais pas dans la méthode equals() : soit de manière externe, soit avec une méthode Transport.sameVersion(Transport) par exemple.

[Metha_Chemista]

Oui oui bien sur je vais comparer d'abord comparer les versions ^^ ! Et seulement ensuite je comparerais les transports avec "equal".