Version imprimable
Bonjour!
Ma question est dans le titre!^^
J'aimerais donc savoir si la puissance de gestion d'Hibernate: listes, cascades... se fait au niveau applicatif (avec bcp de génération de code) ou si elle nécessite le concours d'une Base de Données plus élaborée telle que InnoDB.
Merci!
A ma connaissance Hibernate se limite à très peu de gestion logique des données. On peut supporter qu'il gère la cascade pour les relations du type One-To-Many. En générant des ordres DELETE sur suppression d'une instance de l'entité "maître".
Cependant la cohérence des données est assurée uniquement en fin de transaction (commit) et uniquement par le SGBD. Hibernate n'a aucune connaissance des autres transactions, de la concurrence, etc.
Je crois avoir compris quelque chose et j'aimerais Nemek ton avis là dessus.
Je pense finalement que comme Hibernate dans sa gestion des objets persistants est très paramétrable et s'affranchit du type de base de données dans laquelle les données seront stockées, je pense que c'est bien Hibernate qui gère complètement les données de la base de données suivant la manière dont le code (donc au niveau applicatif a été réalisé).
Je pense que, que la base accepte ou non les Foreign Key (InnoDB ou Myisam), Hibernate gérera la colonne qui fait le lien entre deux table (FK applicative) et suivant les options spécifiées: par exemple supprimer tous les fils lorsque le père l'a été, génèrera lui même le code sql qui fera la jointure sur la colonne FK applicative de la table fils et supprimera chaque fils l'un après l'autre.
Et enfin, (j'ai pas mal réfléchis à la question) j'en conclu que le type de BDD n'a aucun importance pour Hibernate mais qu'une base en InnoDB garantira une sécurité réelle avec une gestion un niveau en dessous par la base de donnée garantissant l'intégrité des données.
Ça me parait logique de cette manière...
Hibernate va gérer de manière logique vos données, de la même manière que vous les géreriez en faisant des requêtes SQL. Cependant, si vous avez comme contrainte une clé étrangère (exemple une facture dépend d'un client) et que vous effacez le client avec hibernate, hibernate n'ira pas s'amuser à faire une requête pour voir si il existe des factures dépendantes du client qui empêcheraient l'effacement. Il va juste lancer la commande DELETE. Si les foreign key ne sont pas gérées dans votre DB, ben a sera le bordel à l'arrivée.
Hibernate nécessite que la BD respecte un minimum les règles du SQL.
tchize_ a entièrement raison.
Hibernate est là pour générer des requêtes SQL ; et faire du Lazy Loading pour les clés étrangères.
Les différentes options que l'on peut spécifier sur les données servent pour beaucoup à la génération du code DDL s'il est demandé (mais je suis absolument contre). A la rigueur il se peut qu'il exploite certaines options pour "optimiser" son fonctionnement mais ne pourra jamais remplacé la cohérence transactionnelle que fourni (ou pas) le SGBD. D'ailleurs comment Hibernate pourait savoir ce que fait un autre processus dans la base de données ?
J'utilise Hibernate avec une base de données MySQL, des tables InnoDB et sans contraintes (pas taper c'est pas moi qui est fait l'application) et si je supprime un élément "maître", les éléments "fils" ne sont pas supprimés. C'est l'application elle-même qui fait le ménage.
EDIT: pour reprendre les termes de tchize_, dans cette application c'est le bordel dans la base de données avec des entité qui ne sont référencés par personne ou qui référence des entités qui n'existent plus.
Oui! Tout à fait d'accord avec vous! Hibernate n'ira pas supprimer le fils si le père l'a été (dans le cas d'un DELETE du père) si l'on a pas spécifié que la liaison fils many-to-one n'est pas d'option cascade ="all-delete-orphan" et il y aura des orphelins en BDD avec des contrainte d'intégrité non respectées probablement même avec un ID résiduelle inexistant dans ID-Pere de la table du fils.
Je pense donc aussi que rien ne peut remplacer l'usage d'une BDD de type InnoDB et de vraies clés étrangères. Mais je crois qu'un code bien fait (avec toutes options spécifiées) peut assurer une bonne cohérence des données dans la BDD avec la seule utilisation d'Hibernate.
on peux croire beaucoup, mais dans les fait, c'est rarement le cas. Il y a souvent des contraintes de clé étrangère qui ne sont pas des liaisons de type fils - père ou dont le pere n'a pas connaissance. Dans ces cas là, impossible de mettre un delete orphan.
La question est plutot de savoir pourquoi vous voulez absolument utiliser une DB qui ne respecte pas le minimum de ce que doit faire une DB :s
Peut-être parce que MyISAM ca dépote grave en lecture/écriture. Mais pour moi rien à avoir avec une base de données mais plutôt des fichiers séquentiels indexés.
Le meilleur code du monde ne pourra pas gérer des problèmes d'isolation, de transaction, de concurrence et encore moins des processus externes.
Merci Nemek!
... cassant Tchize ...
La réponse est que je récupère une application dont les scripts de génération initiale BDD génèrent des tables en InnoDB avec contraintes de clés étrangères...
Il s'avère que j'ai récemment récupéré le dump de l'appli en prod et ce dump fait état de tables étrangement en Myisam. Donc il me faut comprendre cet écart et bien que l'appli fonctionne très bien, évaluer la nécessité de rebasculer vers le InnoDB normalement prévu.
quelqu'un a merdé l'install? :aie:
Concrètement, là ou avec une DB qui gère les clés vous auriez des SQLException, (remontée en HibernateException) et pu dire à l'utilisateur "ha nno, là ca va pas le faire". Vous allez avoir une requete qui réussi et des tables avec des clés étrangères qui pointent nulle part. Et quandon chargera inévitablement plus tard ces lignes corrompues avec hibernate, vosu allez avoir de jolie exception avec Hibernante qui arrivera pas à charger les éléments de la clé étrangère.
Personellement, je préfère l'expression "ça roxe du poney" :aie: Sinon, les version récentes de mysql montrenrt que Innodb et même plus performant que myisam sans tous les problèmes de myisam (problème de verrou, tables corrompues lors d'un crash, etc). Donc c'est tout relatif :pCitation:
Envoyé par Nemek
chose important que tu va perdre aussi et qui peut etre catastrophique pour ton application.
myisam n'a pas de transaction!
Un engine tout contrôlé, transactionnel, etc. plus rapide qu'un engine sans contrôle ?_? Ils ont oublié de maintenir l'engine MyISAM ?Citation:
Envoyé par tchize_
Je dois avouer que mes références remontent à 2006/2007 pour un module d'indexation textuelle écrit en Ruby et utilisant le mode 'embedded' de MySQL.
Partout où j'ai travaillé (gros avionneur européen inside), il y a une règle d'or : ça marche tu touches pas.Citation:
Envoyé par Annsen
Après cela peut provenir de deux cas de figure sur lesquels je suis déjà tombé :
- Le script d'initialisation n'a pas été maintenu par rapport aux évolutions de la base de données.
- Certains scripts de modification (il me semble qu'on ne peut pas changer l'engine d'une table MySQL) n'ont pas été jouer sur la base de données de production.
En tout cas modifier ce genre de paramètre ne peut se faire sans audit (réactivité de l'application, validation des données, etc.)
c'est apparement surtout du à certaines différences majeure de design, sur lesquelles il serait dur de revenir sans casser les DBs existantes:Citation:
Envoyé par Nemek
Par exemple:
-> l'index de myisam est plus condensé mais moins rapide à la consultation que celui de innodb
-> myisam fait du table lock lors des modification, alors que innodb fait du locking par row. Une application qui fait 30% écriture 70% lecture est alors plus rapide avec innodb car pas encombrée par les autres écritures des autres connections.
-> innodb permet apparement du tuning en fonction de tes besoins permettant d'aller jusqu'à un facteur 50 de différences de performances, alros que myisam, tu peux espérer un gain de 2 à 3 par rapport à un config défaut.
-> innodb permet le concurrent locking, ce qui diminue encore les attentes.
Maintenant, c'est ce que je lit quand je fait des recherche sur le sujet, et concrètement, chaque cas est différents.
Innodb est maintenant l'engine par défaut à la place de myisam (cf doc de mysql 5.6);)
OK, j'étais donc dans le cas d'utilisation optimale : écriture en masse par seul processus et en une seule fois, puis requêtage simple toujours par un seul processus.
Merci de vos conseils!
Et merci Nemek de ces précisions sur les raisons qui pourraient expliquer le changement.
Je vais donc ne pas opter pour un changement tant que je n'aurais pas une idée très précise des dysfonctionnements s'il y en a en BDD.
Aka "On attend qua ça pète et on voit après" ^^Citation:
Envoyé par Annsen
j'aurais perso tendance à prendre l'option inverse "l'application est garantei et testée sur innodb, tout autre engine invalide la garantie" :mouarf:
^^
Eh bien pas vraiment en fait.
L'appli a été développée avec du InnoDB et testée dessus c'est sûr et livrée pour du InnoDB mais elle est en prod depuis qqs années mnt et vraisemblablement sur du Myisam...
Un dernier message pour clore la discussion.
Je vais effectuer le changement.
En fin de compte de nombreuses contraintes d'intégrités sons enfreintes, il y a des redondance dans la BDD, et le code tient compte du type d'exception remontées pas une BDD de type InnoDB pour effectuer certains traitements.
Et enfin procéder au changement est très simple alors pourquoi s'en priver.
Voila voila le point est mis.
Merci pour vos aides.