Discussion :

[jMax31]

Bonjour,

C'est mon premier message ici et il est peut-être un peu hors sujet (si vous trouvez que c'est le cas, je m'en excuse par avance), mais j'aimerais quand même avoir l'avis d'experts Qt sur la question.

Voilà : d'un côté j'ai une base PostgreSQL avec une table et une vue (au sens SQL, c'est à dire créée par CREATE VIEW...) basée sur cette table, et d'un autre côté j'ai une appli écrite en QtJambi (le problème serait le même en C++) qui va utiliser cette base.

Le framework Model/View de Qt permet de définir une QTableModel qui constitue un modèle (au sens MVC) correspondant à une table SQL. A l'utilisation, on modifie les données dans cette QTableModel puis on fait un database().commit() pour répercuter les modifs dans la base SQL. Très pratique.

Du point de vue de Qt, les vues PostgreSQL ne présentent aucune différence avec les tables. On peut donc utiliser une vue SQL comme source de données d'une QTableModel. Pas de problème... en tout cas tant qu'on essaie pas de modifier les données car les vues PostgreSQL sont read-only. Je n'ai pas osé essayer un commit() sur une vue, je suis à peu près sûr du résultat.

Pour pouvoir éditer les données la démarche logique est donc d'utiliser la table SQL comme source de données et non plus la vue (1). Mais alors pour présenter les données comme dans la vue il faut réécrire dans le code, l'équivalent de toutes les fonctions PostgreSQL utilisées dans la vue, et comme j'ai passé pas mal de temps à développer toutes ces fonctions pour construire cette vue (assez complexe, en fait), j'aimerais bien éviter d'avoir à me retaper tout le boulot dans le code. D'autant que les premiers tests font apparaitre une chute de perf assez considérable.

Est-ce que vous auriez des idées sur la meilleure façon d'appréhender la question ?

Merci pour toute information à ce sujet.

jMax

(1) Parler de vue comme source de données d'un modèle paraitra certainement très bizarre aux spécialistes du MVC, mis ne perdons pas de... vue (justement ) qu'il s'agit là de vues SQL, c'est à dire de conteneurs de données.

[yan]

Bonjour et bien venue sur le forum.
Je n'ai pas tout compris a ton problème...
Mais on ne sait jamais, as tu regardé ces class??
http://qt.developpez.com/doc/4.3/qsq...model/#details
http://qt.developpez.com/doc/4.3/qsq...model/#details

[IrmatDen]

Salut,

Tu devrais tenter en surchargeant les méthodes protégées QSqlTableModel::updateRowInTable, QSqlTableModel::insertRowIntoTable et QSqlTableModel::deleteRowFromTable pour modifier les sources réelles.
Par contre, c'est à toi de mapper les indices de lignes sur l'enregistrement source, ainsi que d'extraire les parties correspondantes de QSqlRecord pour les utiliser à l'entroit mappé précedemment.

(A noter que je ne jamais testé, mais que c'est par là que je commencerais si j'étais dans ton cas).

[jMax31]

Bonjour !

L'idée de surcharger les méthodes adéquates dans QSqlTableModel me parait tout à fait intéressante. Le plus propre serait peut-être de le faire avec un proxyModel customisé (héritant directement de QAbstractProxyModel) en réimplémentant les fonctions de mapping et d'index.

Bon, je vais faire des protos pour voir ce que ça donne ne terme de perfs et je crois que je déciderai à partir de là...

En tout cas merci pour cette très bonne idée.

Cordialement

jMax

[IrmatDen]

Je ne suis pas sûr que ce genre de manip soit à déléguer dans un proxy. Après tout, ça reste le modèle original qui fait la gestion du lien données DB <-> applis.

Je suis curieux de connaître le résultat de tes investigations, ça peut toujours être utile