手动更改后数据库记录还原

时间:2021-02-15 07:56:12

Problem solved: Thanks guys, see my answer below.

问题解决了:谢谢你们,请看下面的答案。

I have a website running in Tomcat 5.5 hooked up to a MySQL5 database using Hibernate3.

我有一个运行在Tomcat 5.5中的网站使用Hibernate3连接到MySQL5数据库。

One record simply refuses to keep any changes performed on it. If I change the record programmatically, the values revert back to what they were previously.

一条记录只是拒绝对其进行任何更改。如果我以编程方式更改记录,则值将恢复为之前的值。

If I manually modify the record in the database, the values will revert (seemingly once the webapp accesses them).

如果我手动修改数据库中的记录,则值将恢复(似乎一旦webapp访问它们)。

I have tried stopping Tomcat and changing the values manually then starting Tomcat again. Checking the database, the values remain changed after Tomcat has started the webapp but will revert back again once I load the site.

我已经尝试停止Tomcat并手动更改值,然后再次启动Tomcat。检查数据库后,Tomcat启动Web应用后值仍会更改,但在加载站点后将再次恢复。

I have also tried deleting the Tomcat work folder for the webapp and the .ser cache file.

我还尝试删除webapp和.ser缓存文件的Tomcat工作文件夹。

I have also checked the code for the values that are being reverted to and cannot find them.

我还检查了代码中的值,这些值正被还原为无法找到它们。

I have only noticed it on this one particular record.

我只注意到这一个特定记录。

Edit: I've just had a look at the SQL output from Hibernate using hibernate.show_sql=true. There is an update query logged for the table my row is in. Does anyone know how to resolve the ? for the columns to actual values?

编辑:我刚刚看了一下使用hibernate.show_sql = true的Hibernate的SQL输出。我的行所在的表中记录了更新查询。有谁知道如何解决?列到实际值?

6 个解决方案

#1


1  

You could temporarily enable the mysql query logging and see exactly what sql statement altered the value. Since you say it changes immediately after the server starts you should be able to figure out the statement pretty quickly.

您可以暂时启用mysql查询日志记录,并确切地查看sql语句更改了该值的内容。既然你说它在服务器启动后立即发生了变化,那么你应该能够很快找出这个语句。

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

#2


1  

To answer your question:

回答你的问题:

Does anyone know how to resolve the ? for the columns to actual values?

有谁知道如何解决?列到实际值?

You can do this with p6spy. Instructions for how to set this up in a Spring app are available here.

你可以用p6spy做到这一点。有关如何在Spring应用程序中进行设置的说明,请点击此处。

However, I think there's a mistake in these instructions, the file they refer to as p6spy.log should actually be name p6spy.properties.

但是,我认为这些指令存在错误,它们称为p6spy.log的文件实际上应该是名称p6spy.properties。

#3


0  

It's getting close to halloween, so you have to expect this sort of thing (plus it was just a full moon), but I'd keep looking for the culprit in the web application ... it HAS to be there. A couple values I'd immediately search for in the webapp source code:

它越来越接近万圣节,所以你不得不期待这种事情(加上它只是一个满月),但我一直在寻找网络应用程序的罪魁祸首...它必须在那里。我会立即在webapp源代码中搜索一些值:

  • The id of the record being changed.
  • 正在更改记录的ID。

  • The value that's being written into the record.
  • 正在写入记录的值。

Good luck ... these can be real bears to find!

祝你好运......这些可以找到真正的熊!

#4


0  

This smells a little like a test-case firing on start up that modifies the row to what it expects it to be before testing.

这有点像启动时的测试用例,它会在测试之前将行修改为预期的行。

#5


0  

Add a trigger BEFORE UPDATE, check row id, raise an SQL error if it matches your magic row. Then check the generated stacktrace, walk the code and locate the piece that updates the row.

在BEFORE UPDATE之前添加一个触发器,检查行id,如果它与您的魔术行匹配则引发SQL错误。然后检查生成的堆栈跟踪,遍历代码并找到更新行的部分。

#6


0  

Thanks to everyone for the help. All of the suggestions came in handy for tracking it down.

感谢大家的帮助。所有这些建议都可以用来追踪它。

I've managed to find out what was causing it. Bad database design, multiple data models and Hibernate makes for some nasty stuff. Another table had the value stored and that class was extending a base class with the same value.

我设法找出导致它的原因。糟糕的数据库设计,多种数据模型和Hibernate使得一些讨厌的东西。另一个表存储了值,该类正在扩展具有相同值的基类。

Time to look at doing some normalisation.

是时候看看做一些规范化了。

#1


1  

You could temporarily enable the mysql query logging and see exactly what sql statement altered the value. Since you say it changes immediately after the server starts you should be able to figure out the statement pretty quickly.

您可以暂时启用mysql查询日志记录,并确切地查看sql语句更改了该值的内容。既然你说它在服务器启动后立即发生了变化,那么你应该能够很快找出这个语句。

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

#2


1  

To answer your question:

回答你的问题:

Does anyone know how to resolve the ? for the columns to actual values?

有谁知道如何解决?列到实际值?

You can do this with p6spy. Instructions for how to set this up in a Spring app are available here.

你可以用p6spy做到这一点。有关如何在Spring应用程序中进行设置的说明,请点击此处。

However, I think there's a mistake in these instructions, the file they refer to as p6spy.log should actually be name p6spy.properties.

但是,我认为这些指令存在错误,它们称为p6spy.log的文件实际上应该是名称p6spy.properties。

#3


0  

It's getting close to halloween, so you have to expect this sort of thing (plus it was just a full moon), but I'd keep looking for the culprit in the web application ... it HAS to be there. A couple values I'd immediately search for in the webapp source code:

它越来越接近万圣节,所以你不得不期待这种事情(加上它只是一个满月),但我一直在寻找网络应用程序的罪魁祸首...它必须在那里。我会立即在webapp源代码中搜索一些值:

  • The id of the record being changed.
  • 正在更改记录的ID。

  • The value that's being written into the record.
  • 正在写入记录的值。

Good luck ... these can be real bears to find!

祝你好运......这些可以找到真正的熊!

#4


0  

This smells a little like a test-case firing on start up that modifies the row to what it expects it to be before testing.

这有点像启动时的测试用例,它会在测试之前将行修改为预期的行。

#5


0  

Add a trigger BEFORE UPDATE, check row id, raise an SQL error if it matches your magic row. Then check the generated stacktrace, walk the code and locate the piece that updates the row.

在BEFORE UPDATE之前添加一个触发器,检查行id,如果它与您的魔术行匹配则引发SQL错误。然后检查生成的堆栈跟踪,遍历代码并找到更新行的部分。

#6


0  

Thanks to everyone for the help. All of the suggestions came in handy for tracking it down.

感谢大家的帮助。所有这些建议都可以用来追踪它。

I've managed to find out what was causing it. Bad database design, multiple data models and Hibernate makes for some nasty stuff. Another table had the value stored and that class was extending a base class with the same value.

我设法找出导致它的原因。糟糕的数据库设计,多种数据模型和Hibernate使得一些讨厌的东西。另一个表存储了值,该类正在扩展具有相同值的基类。

Time to look at doing some normalisation.

是时候看看做一些规范化了。