手动更改后恢复数据库记录

发布于 2024-07-06 14:09:42 字数 566 浏览 7 评论 0原文

问题已解决:谢谢大家,请参阅下面的我的回答。

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

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

如果我手动修改数据库中的记录,这些值将恢复(似乎一旦 Web 应用程序访问它们)。

我尝试停止 Tomcat 并手动更改值,然后再次启动 Tomcat。 检查数据库,Tomcat 启动 Web 应用程序后,这些值仍然保持更改,但一旦我加载站点,这些值就会再次恢复。

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

我还检查了正在恢复的值的代码,但找不到它们。

我只在这张特定的记录上注意到这一点。

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

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.

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).

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.

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

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

也只是曾经 2024-07-13 14:09:42

您可以暂时启用 mysql 查询日志记录并准确查看哪些 sql 语句更改了该值。 既然您说它在服务器启动后立即发生变化,您应该能够很快地弄清楚该语句。

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

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.

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

情释 2024-07-13 14:09:42

回答你的问题:

有谁知道如何解决吗?
将列设置为实际值?

您可以使用 p6spy 来执行此操作。 有关如何在 Spring 应用程序中进行设置的说明,请参阅 这里

但是,我认为这些说明中有一个错误,他们引用的 p6spy.log 文件实际上应该是 p6spy.properties。

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.

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

合久必婚 2024-07-13 14:09:42

万圣节快到了,所以你必须预料到会发生这种事情(而且当时只是满月),但我会继续在网络应用程序中寻找罪魁祸首……它必须在那里。 我会立即在 web 应用程序源代码中搜索几个值:

  • 正在更改的记录的 id。
  • 正在写入的值
    记录。

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

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:

  • The id of the record being changed.
  • The value that's being written into
    the record.

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

魂归处 2024-07-13 14:09:42

这听起来有点像启动时触发的测试用例,该测试用例将行修改为测试前的预期值。

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.

羞稚 2024-07-13 14:09:42

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

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.

初见你 2024-07-13 14:09:42

感谢大家的帮助。 所有的建议都有助于追踪它。

我已经设法找出是什么原因造成的。 糟糕的数据库设计、多种数据模型和 Hibernate 会导致一些令人讨厌的事情。 另一个表存储了该值,并且该类正在扩展具有相同值的基类。

是时候考虑进行一些标准化了。

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.

Time to look at doing some normalisation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文