Enregistrement de base de données inversé après modification manuelle

Question

Problème résolu: Merci les gars, voir ma réponse ci-dessous.

J'ai un site Web sous Tomcat 5.5 connecté à une base de données MySQL5 avec Hibernate3.

Un enregistrement refuse simplement de conserver les modifications effectuées. Si je modifie l'enregistrement par programme, les valeurs reviennent à ce qu'elles étaient auparavant.

Si je modifie manuellement l'enregistrement dans la base de données, les valeurs seront restaurées (apparemment une fois que l'application Web les aura accédées).

J'ai essayé d'arrêter Tomcat et de modifier les valeurs manuellement, puis de redémarrer Tomcat. En vérifiant la base de données, les valeurs restent modifiées après le démarrage de l'application Web par Tomcat, mais elles reviendront une fois que je chargerai le site.

J'ai également essayé de supprimer le dossier de travail Tomcat pour l'application Web et le fichier de cache .ser.

J'ai également vérifié dans le code les valeurs renvoyées et ne les trouve pas.

Je ne l'ai remarqué que sur cet enregistrement particulier.

Modifier: Je viens d'examiner la sortie SQL d'Hibernate à l'aide de hibernate.show_sql = true. Une requête de mise à jour est consignée pour la table dans laquelle se trouve ma ligne. Est-ce que quelqu'un sait comment résoudre le problème? pour les colonnes aux valeurs réelles?

Answer 1

Vous pouvez activer temporairement la journalisation de la requête mysql et voir exactement quelle instruction SQL a modifié la valeur. Puisque vous dites que cela change immédiatement après le démarrage du serveur, vous devriez être en mesure de comprendre la déclaration assez rapidement.

http://dev.mysql.com/doc /refman/5.0/en/query-log.html

Answer 2

Pour répondre à votre question:

  

Est-ce que quelqu'un sait comment résoudre le?   pour les colonnes aux valeurs réelles?

Vous pouvez le faire avec p6spy . Les instructions pour configurer cela dans une application Spring sont disponibles ici .

Cependant, je pense qu'il y a une erreur dans ces instructions: le fichier qu'ils appellent p6spy.log devrait en fait s'appeler p6spy.properties.

Answer 3

On se rapproche de Halloween, il faut donc s'attendre à ce genre de chose (en plus, c'était juste la pleine lune), mais je continuerais à chercher le coupable dans l'application Web ... il DOIT y être. Quelques valeurs à rechercher immédiatement dans le code source de l'application Web:

• L'id de l'enregistrement en cours de modification.
• La valeur en cours d'écriture l'enregistrement.

Bonne chance ... ce peuvent être de vrais ours à trouver!

Answer 4

Cela sent un peu comme un déclenchement de test au démarrage qui modifie la ligne comme elle le devrait avant les tests.

Answer 5

Ajoutez un déclencheur AVANT UPDATE, vérifiez l’id de la ligne, générez une erreur SQL si elle correspond à votre ligne magique. Puis vérifiez le stacktrace généré, parcourez le code et localisez la pièce qui met à jour la ligne.

Answer 6

Merci à tous pour votre aide. Toutes les suggestions ont été utiles pour le retrouver.

J'ai réussi à découvrir ce qui le causait. Une mauvaise conception de base de données, plusieurs modèles de données et Hibernate en font des choses désagréables. Une autre table avait la valeur stockée et cette classe étendait une classe de base avec la même valeur.

Il est temps d’envisager une normalisation.