dataModel DB updatable pour JTable ?

Je browse, Google, cherche mais ne trouve rien pour un dataModel de rowset updatable générique.

J'entends par générique que l'on remplis une Jtable avec l'équivalent de 'select * from table' dans un Jtable et on update/insert/delete avec commit immédiate ou retarde en batch.
Je sais que pour JDBC c'est deja raté, car Select * ...' ne remplis pas les metadata et il faut donc faire un select column_name from all_table_column where table_name ='?' and owner = '?' Mais ca ca va encore.

Comme on a resultset.metadata qui contient les types de colonnes, il semble qu'on aie tout pour maintenir un dataModel avec les rowset.absolute(x) suivit de rowet.updatexxx(typeobj). Mais c'est loin d'être évident a réaliser.

Par exemple, faire un add d'un row dans mon Jtable qui se reportera a la table DB semble facile a première vue, mais 2 problèmes surviennent :

1) Il faut créer un row dont chaque colonne a le type équivalent a celui chargé au depart de la table pour chaque colonne. On serait tenté de prendre le même type que le type de la colonne, mais une table vide, qui a le droit d'etre populee, a un dataModel vide. Il faut alors se reporter a resultset.metadata.

2) Seule les colonnes qui seront effectivement remplie doivent être traitées en update dans le rowset, les autres doivent rester 'null' sauf si la colonne a une default value. Bref les cas s'enchaînent.

Ma question est :

Quelqu'un a déjà vu un dataModel générique pour une DB? Si je ne trouve rien, je pourrais toujours poster ce que j'ai déjà, mais j'ai plein de bug avec les TableSorter et les rowzebra car établir une fonction getColumnClass qui tient la route c'est pas aussi évident que ca en a l'air. J'ai meme pas encore entame les TableCellEditor : un pour chaque type connu de la DB.

J'entame cet exercice car je pensais connaître les Jtable jusqu'au moment ou j'ai essayé un rowset updatable. Java m'a filé une claque dont je me remet pas

Je me réponds à moi-même: la solution semble être d'utiliser Top-Link qui est une implémentation JPA.

Euh, dans le cas présent je pencherais plutôt pour ne pas laisser au modèle la responsabilité de s'occuper de la communication avec la base de données, ce n'est absolument pas son rôle. D'autant plus qu'il te faudra user d'acrobaties pour éviter de bloquer l'EDT lors de la modification de ta JTable.

J'aurais plutôt tendance à déléguer ce genre de tâches au contrôleur que tu devrais normalement créer dans une archi MVC, contrôleur qui réalisera la récupération/modification/insertion/suppresion des données via une archi à base de DAO et de classes agnostiques, genre une classe Row, une classe Column, une Classe Table pour la description de la Table en passant par des DatabaseMetaDatas, la classe Column pouvant éventuellement contenir la donnée en elle même.

Avec ceci tu devrais avoir de quoi réaliser un TableModel relativement malléable se basant sur un objet de type Table contenant, des DAO pas trop bêtes avec de la génération de code SQL à la volée à partir des objets fournis et ainsi de suite.


EN bref pour moi mélanger TableModel et Rowset JDBC est une erreur au niveau Architecture, c'est pas vraiment fait pour marcher de façon correct ensemble.

Pour une DAO j'ai regardé Hibernate et JPA. Mon application est un client lourd connecté via JDBC en permanence. Donc j'ai éliminé hibernate et je me tate entre une des implémentation de JPA ou bien un objet maison. Mais les JPA ne semblent pas plus simple surtout qu'ils semblent être fait pour des metadata connue a l'avance. Si il n'y a aucune implémentation simple (et il ne semble pas y en avoir) alors autant allez pour le dernier choix et apprendre.

L'une des particularité est que je me propose de mapper n'importe qu'elle table d'un schéma à la volée. Donc pas de ficher XML préparé a l'avance. Le modèle de base du mapping des tables et vues (structure et data) est 'select * ' avec upate/delete/insert (je tient compte des restriction sur les vues). L'appli est en droit de consulter toutes les metadata et ce y compris le data dictionary de la DB si nécessaire (utile pour les constraintes, les default values, PK, FK etc...)


Je ne suis pas pressé mais plutôt déterminé à faire mon objet, aussi je prend le temps de prospecter. Je te remercie pour tes indications et objections.

Je vais les méditer (et essayer de comprendre ce que tu dis) car je suis partit depuis une semaine sur une tableModel overload qui maintient une correspondance entre le dataModel et le rowset. Je me perd grave entre les OracleRowset, les OracleResultSet et JDBCrowSet pour ne pas parler des OracleJDBCRowSet. Difficile de se retrouver dans cette jungle pour savoir quel objet irait le mieux. De plus les fireEvent un peu partout dans la Jtable et dataModel me rendent la vie pénible. Je joue au pompier et ca sent l'usine a gas, j'en suis conscient.