Восстановление записи базы данных после ручного изменения
Проблема решена: Спасибо, ребята, см. Мой ответ ниже.
У меня есть веб-сайт, работающий в Tomcat 5.5, подключенный к базе данных MySQL5 с помощью Hibernate3.
Одна запись просто отказывается сохранять какие-либо изменения, внесенные в нее. Если я изменю запись программно, значения вернутся к прежним значениям.
Если я вручную изменю запись в базе данных, значения вернутся (по-видимому, как только веб-приложение обратится к ним).
Я попытался остановить Tomcat и вручную изменить значения, а затем снова запустить Tomcat. При проверке базы данных значения остаются измененными после того, как Tomcat запустил веб-приложение, но вернутся обратно после загрузки сайта.
Я также попытался удалить рабочую папку Tomcat для веб-приложения и файл кеша .ser.
Я также проверил код значений, к которым выполняется возврат, и не могу их найти.
Я заметил это только на одной конкретной записи.
Редактировать: Я только что взглянул на вывод SQL из Hibernate, используя hibernate.show_sql = true. Для таблицы, в которой находится моя строка, зарегистрирован запрос на обновление. Кто-нибудь знает, как разрешить ошибку? для столбцов к фактическим значениям?
Ответы 6
Приближается Хэллоуин, поэтому вы должны ожидать такого рода вещей (к тому же это было просто полнолуние), но я бы продолжал искать виновника в веб-приложении ... он ДОЛЖЕН быть там. Пара значений, которые я бы сразу нашел в исходном коде веб-приложения:
- Идентификатор изменяемой записи.
- Значение, которое записывается в запись.
Удачи ... это могут быть настоящие медведи!
Хммм ... Я не знаю, куда вам указать, не глядя на код и / или структуру таблицы. Вы используете Hibernate3 в качестве провайдера JPA или просто Hibernate? С файлами hbm, javadoc / xdoclet или аннотациями?
Использование его как JPA с доклетом. Я предполагаю, что это где-то в Webapp, а не в самой базе данных, поскольку дамп на другой машине дает те же результаты.
Как вы генерируете значения для своих ПК (идентификаторов)? Возможно ли, что генератор выходит из строя и выдает значение в PK изменяемой записи?
Hibernate обрабатывает PK (generator-class = "increment"). Как мне проверить, не выходит ли из строя генератор?
Пришлось поискать это ... и я считаю, что это правильно для MySQL (и я предполагаю, что определение вашего поставщика использует MySQLDialect).
Диалект - org.hibernate.dialect.MySQL5Dialect.
Это немного похоже на запуск тестового примера при запуске, который изменяет строку до ожидаемой до тестирования.
Хороший ... Тесты JUnit для POJO или настройки DBUnit могут сделать это ... Престижность!
К сожалению, для этого конкретного веб-приложения написано очень мало тестов. Из тех, что есть, ни один не написан таким образом, чтобы (явно) изменять записи.
Добавьте триггер ПЕРЕД ОБНОВЛЕНИЕМ, проверьте идентификатор строки, вызовите ошибку SQL, если она соответствует вашей волшебной строке. Затем проверьте сгенерированную трассировку стека, просмотрите код и найдите фрагмент, который обновляет строку.
Добавлен перехватчик в SessionFactory (с использованием Spring) Кажется, он не использует? <property name = "entityInterceptor"> <ref bean = "myInterceptor" /> </property> <bean id = "myInterceptor" class = "com.blah.TestInterceptor" /> TestInterceptor имеет след в onSave ().
Вы можете временно включить ведение журнала запросов mysql и посмотреть, какой именно оператор sql изменил значение. Поскольку вы говорите, что он изменяется сразу после запуска сервера, вы сможете довольно быстро вычислить оператор.
http://dev.mysql.com/doc/refman/5.0/en/query-log.html
Включил, проверил логи и да, выполняется запрос на обновление записи. Узнать, откуда он исходит, - сложная часть.
Чтобы ответить на ваш вопрос:
Does anyone know how to resolve the ? for the columns to actual values?
Вы можете сделать это с помощью p6spy. Инструкции по настройке этого в приложении Spring доступны здесь.
Однако я думаю, что в этих инструкциях есть ошибка: файл, который они называют p6spy.log, на самом деле должен называться p6spy.properties.
Спасибо всем за помощь. Все предложения пригодились для его отслеживания.
Мне удалось выяснить, чем это было вызвано. Плохой дизайн базы данных, несколько моделей данных и Hibernate создают неприятные вещи. В другой таблице было сохранено значение, и этот класс расширял базовый класс с тем же значением.
Пора заняться нормализацией.
К сожалению, я попытался найти в коде значения, к которым он возвращается, и никаких кубиков.