Discussion :

[vikki]

Bonjour à tous,

J'utilise actuellement un QTableView avec un QSqlRelationalTableModel pour pouvoir afficher et modifier le contenu d'une base de données SQL.
Le problème est que j'aimerais insérer une colonne en fin du QTableView contenant des images associées à chaque ligne.
J'ajoute la colonne avec la fonction insertColomn du QSqlRelationalTableModel, celle ci apparait bien à la creation du widget mais disparait dès que j'interagis avec mon QTableView. J'imagine que pour ajouter une colonne de plus que celles contenues dans ma base SQL, il faille re-implémenté un model héritant de QSqlRelationalTableModel.
Quelqu'un aurait-il une idée sur la marche à suivre?

[alcino]

Salut,

Je n'ai pas testé, mais tu peux peut-être utiliser un QTableWidget à la place de ton QTableView. Ça te permettrait d'utiliser la fonction insertColumn() du QTableWidget, et tu n'aurais peut-être plus le même problème. A tester !

Bonne chance
A+

[_skip]

Quels sont les fonctionnalités que tu utilises dans cette classe? Tu fais que de l'affichage, tu édites?

[vikki]

Je n'ai pas testé, mais tu peux peut-être utiliser un QTableWidget à la place de ton QTableView. Ça te permettrait d'utiliser la fonction insertColumn() du QTableWidget, et tu n'aurais peut-être plus le même problème. A tester !

En fait j'aimerais vraiment conserver le QTableView pour exploiter la puissance du QSQLTableModel...

Quels sont les fonctionnalités que tu utilises dans cette classe? Tu fais que de l'affichage, tu édites?

On s'en sert pour les deux: affichage du contenu de la base et modification via les widget générés par le QSQLTableModel (notamment les QComboBox représentant une énumération via clé étrangère dans la base de données).
Mas bon, si c'est vraiment misérable à utiliser (et ca semble l'être) on va peut être switcher sur le QTableWidget.

[alcino]

En fait j'aimerais vraiment conserver le QTableView pour exploiter la puissance du QSQLTableModel...

QTableWidget hérite de QTableView... Tu ne peux donc pas perdre des fonctionnalités, seulement en gagner . De plus tu n'es pas obligé de réécrire ton code...

Bonne chance

[_skip]

On s'en sert pour les deux: affichage du contenu de la base et modification via les widget générés par le QSQLTableModel (notamment les QComboBox représentant une énumération via clé étrangère dans la base de données).
Mas bon, si c'est vraiment misérable à utiliser (et ca semble l'être) on va peut être switcher sur le QTableWidget.

Au risque de me faire des ennemis, je trouve que ces classes SQLModel, hormis pour du prototypage, ne valent pas grand chose. Le support pour la validation métier est assez limité, sitôt qu'on s'éloigne de la présentation 1:1 entre la table SQL et la table Qt ça devient la galère.

bref j'implémenterai mon propre modèle à ta place.

[vikki]

Bon, après de nombreux jours de tests, j'enfile ma camisole et me tape la tête contre un mur. Les classes SQLModel sont vraiment infâmes, on est d'accords. C'est ballot, on a déjà tous développé autour d'elles donc on va les garder quand même, mais on évite les petites subtilités du genre "et si je voulais insérer dans ma table view..."

[_skip]

Je suis arrivé aux mêmes conclusions. Ces modèles sont pratiques pour faire rapidement un pont entre la BDD et la GUI mais ça s'arrête là.

Si ça peut t'aider, voici comment je m'y prend :

Perso je charge les données dans des QList d'objets métier que j'affiche via un modèle, et je gère moi même l'édition et la validation. Je sais que certains diront que c'est du code pour rien, que c'est plus lent etc...

En vérité, je charge quasiment jamais plus de 500 lignes à la fois de la BDD en utilisant des SELECT TOP, la raison est simple : ça sert à rien de laisser l'utilisateur scroller sur 50'000 enregistrements, ça fait exploser la mémoire pour rien, ça multiplie les allers-retours BDD, sans compter qu'il faut une connexion ouverte pour le fetch partiel.
Il faut plutôt lui fournir un ou 2 champs dans l'interface utilisateur pour trouver plus facilement ce qu'il veut, dans le cas d'une table contenant des produits, une combo catégorie ou un champ de texte pour taper les premières lettres du nom sont mille fois plus rapides et confortables que scroller dans tous les sens.

L'ajout de nouvelles entrées, je le fais par une autre fenêtre de formulaire et non directement dans la table à part pour les vraiment petites choses. Ca me permet de signaler les champs obligatoires, de mettre des infos-bulle d'aide, et d'utiliser ma façade métier pour la validation et balancer moi-même la requête insert/update. J'y gagne que tout ce code de validation/modification est utilisable ailleurs dans mon application, entièrement par code, même sans formulaire et sans tableview.

Les seules choses que je laisse modifier directement sur la tableview, ce sont les petites modifs que l'on fait sans arrêt (changer l'état d'une commande, modifier une quantité) afin d'éviter de devoir passer par le formulaire complet, mais là encore j'utilise la fonction setData() et je fais moi même l'update via ma couche métier.

Voilà, c'est peut être un peu plus lent à développer, mais au moins l'affichage et l'édition sont bien séparés, le code est réutilisable et peut être blindé par des tests unitaires et c'est selon moi beaucoup plus propre que laisser des composants GUI balancer des requêtes au petit bonheur la chance et gérer les erreurs à leur façon.

[vikki]

On est bien d'accords, la prochaine fois que je ferais face à ce type de problème (gestion de BDD avec table viewer), je ferais ca proprement, à la main, avec un bon vieux QTableWidget . Simplement, c'est rageant de découvrir ca si tard dans l'avancement du projet... Sinon, j'avais pas pensé au cas des 50000 entrées devant être affichées, j'espère que ca va pas nous arriver (loi de Murphy oblige, ca arrivera).