Idées pour modifier de manière dynamique les champs d'une base MySQL à partir de Java

Bonjour à tous.

Je suis en pleine programmation d'un programme scientifique écrit en Java SE, relié à une base MySQL via l'utilisation d'Hibernate pour la création d'objets persistants.

Ma question est assez générique : tout en sachant qu'il est tout à fait possible de rajouter des champs dans les tables de ma base via une instruction SQL, auriez-vous des idées pour le faire à partir de mon code Java?
En quelque sorte, puis-je rendre persistant de manière dynamique ces nouveaux champs de la base renseignés par l'utilisateur au travers de l'interface graphique de mon programme java?

Je ne recherche pas de codes mais des idées pour que mon interface graphique java réagisse de manière dynamique avec la base de données.

Merci d'avance pour toutes vos suggestions et bonne journée.

C'est bien le but d'Hibernate...

Tu peut ajouter, supprimmer et modifier des données de la base et traiter le tout sous forme d'objets. C'est bien ça que tu veux ?

Ok j'ai bien compris ton but, mais si je me souviens bien tu ne peux pas ajouter de champs obligatoire sans valeur par défaut à une table deja crée avec des données dedans. Donc il faut faire attention à cela, à moins que tu ne reconstruise ta base via hibernate à chaque changement, ;)

... ou tu veux modifier le schéma dynamiquement?
Si tel est le cas... Tu n'es pas sorti d'affaire!
Conceptuellement, je pense que cela traduit une imperfection de design. Mais si je me trompe alors il faudra pour chaque modification dans le schema non seulement reloader la session factory après avoir modifier les mappings mais par extension toutes tes entités seront elle-même des classes dynamiques modifier par réflection pour qu'ils aient également les "nouveaux" champs!
C'est un casse-tête rigolot, mais je ne suis pas sûr qu'il soit utils, si? Ou je complique inutilement ta question et wichtounet la bien comprise lui!
Alex

Il y a peut-être un autre aspect de la question à prendre en compte.
OK, en sql natif, on peut modifier la structure d'une table, ajouter, supprimer etc (alter table, drop table...), mais comment faire, après pour qu'hibernate s'adapte ? Tu veux modifier les fichiers de mapping, arrêter/redémarrer pour qu'hibernate soit à niveau ?
Je ne pense pas que ce soit possible (hors usine à gaz)...

A+

Usine à gas clairement!
De plus, si c'est un environnement multi-threader, c'est même très ennuyant! Et le cache level 2 dans tout ça? Et les "longues" transaction? Et...?
Mais tu es bien certain que c'est vraiment nécessaire? A nouveau, je pense sincèrement qu'il a plus une erreur de conception?! Je ne conçois pas que la business logic (logique métier?!) modifie le schéma de la base de données!
Alex

Citation:

---

Envoyé par a.snaps

Usine à gas clairement!
De plus, si c'est un environnement multi-threader, c'est même très ennuyant! Et le cache level 2 dans tout ça? Et les "longues" transaction? Et...?
Mais tu es bien certain que c'est vraiment nécessaire? A nouveau, je pense sincèrement qu'il a plus une erreur de conception?! Je ne conçois pas que la business logic (logique métier?!) modifie le schéma de la base de données!
Alex

---

Entièrement d'accord ! Conceptuellement, je tilt...
Le seul outil (pertinant) que je vois succeptible de faire ce genre de chose serait un gestionnaire de base de données. Et là, on n'utilise pas Hibernate, mais JDBC et les meta-data

On ne se comprends pas. Je ne pense pas que ce soit l'outil le problème! Mais plus le fait de modifier ce schéma programmatiquement!
Sauf si tu me dis que tu programmes un outil de gestion de DB! Alors entièrement d'accord... Mais sinon, je vois pas désolé.
Alex

Merci pour tout, mais la but est vraiment de modifier la base via java.

ex : l'utilisateur lance le programme, puis il décide de rajouter un champs "CHPS" à la table X via une interface présente ds la programme java.
Ceci est facile via la commande

Code:

---

Alter table...add

---

.

Maintenant, et c'est mon but même si c'est l'usine à gaz, je veux que l'utilisateur puisse travailler s'il en fait le choix, sur la table X où CHPS a été ajouté.
Il doit être capable de modifier les valeurs de ce nouveau champs par le programme.

Merci encore pour vos idées sur ce débat, mais je sens que la programmation va être très longue...

Longue je ne sais pas, mais Hibernate ne fera pas partie de la solution je pense...
Alex

Citation:

---

Envoyé par a.snaps

Usine à gas clairement!
De plus, si c'est un environnement multi-threader, c'est même très ennuyant! Et le cache level 2 dans tout ça? Et les "longues" transaction? Et...?
Mais tu es bien certain que c'est vraiment nécessaire? A nouveau, je pense sincèrement qu'il a plus une erreur de conception?! Je ne conçois pas que la business logic (logique métier?!) modifie le schéma de la base de données!
Alex

---

Malheuresement, les utilisateurs veulent cette possibilité.
Ce sont des ingénieurs aéronautiques qui modifient leurs modules de calcul très souvent en y rajoutant plein de variables.
Il est vrai que le pb serait résolu en livrant un update du programme à chaque modification lourde de la base.
Mais ils veulent éviter ça...

Modifier la base, pas de pb.
Mais la mapper et créer des objets persistants de manière dynamique...chaud.

Le seul moyen peut-être est de revoir la conception de la base, et au lieu de penser en colonnes (champs), tou faire pour que cela se traduise par des lignes(valeurs de champs).

La solution vient peut-être de Java Web Start.
Ainsi, moi développeur, je modifie mon programme à chaque rajout de champs, et les utilisateurs télécharge selon leurs choix la mise à jour...

J'opterais pour ne plus penser en champs...
Mais t'as des aggrégation de fou à faire? Ou tout se passe dans ton app?
Parce que la DB pour ca peut être un sacrée plus sinon!
Alex

Merci à tous et plus particulièrement à Alex pour toute votre aide qui m'a montré l'étendue de la tâche.
A bientôt.