Отслеживание изменений экземпляров класса и их ассоциаций — мысли?

У меня есть вопрос класса, в котором много связанных моделей. На одной странице моего приложения я перечисляю сводку всех текущих вопросов с различной информацией из связанных записей. В конечном счете, это хэш значений, которые я затем просто распечатываю в строку в стиле csv (далее я буду называть это «хэшем строки»)

Теперь у меня есть требование показывать только изменения вопросов (или связанных с ними данных) за определенный период. В настоящее время я обдумываю лучший способ сделать это. Вот некоторые идеи, которые у меня были до сих пор, я буду рад любым отзывам, мыслям, предложениям и т.

1) Подход 1 - act_as_audited Это была моя первая мысль, так как я использовал это раньше в других приложениях. Однако проблема с aaa заключается в том, что он отслеживает только изменения в данных записи (т.е. ему все равно, изменяются ли ассоциации). Таким образом, я мог бы также проверить все связанные записи, но затем попытка собрать воедино то, что изменилось, связав вместе разные записи аудита, звучит как кошмар.

2) Сохраните старый и новый хэш в сериализованных полях: т.е. - когда кто-то переходит на страницу вопроса/редактирования, я вычисляю хэш текущей строки и сохраняю его в сериализованном поле «old_data» в таблице вопросов. Затем, после того, как они сохранят вопрос, я вычисляю новый хэш текущей строки и сохраняю его в сериализованном поле «new_data» в таблице вопросов. Кроме того, я сравниваю два сериализованных хэша и сохраняю различия в другом сериализованном хеш-поле «изменения». Теперь, чтобы сделать свой отчет, я просто ищу вопросы, обновленные за последние x дней, и вывожу данные об их изменениях.

3) создать представление - я создаю представление, которое соответствует данным, которые я хочу вывести (т.е. оно объединяет все данные, которые я извлекаю в свой отчет). Затем я отслеживаю изменения в представлении - как-то. Я не уверен, как именно я бы это сделал.

Я сейчас склоняюсь ко второму варианту.

Любые другие мысли/комментарии? благодарен за любые предложения - макс.


person Max Williams    schedule 14.07.2010    source источник


Ответы (3)


Итак, как вы сказали, вы хотите показать изменения в записях только между временем x и временем y, верно? Мне это кажется идеальным с помощью плагина act_as_audited, потому что в итоге вы получите таблицу изменений, верно? Поэтому создайте связь has_many_through из Question со всеми этими связанными таблицами, затем найдите в ней связанные изменения, где дата создания — после времени X. Это вернет список изменений. Оттуда вы можете подключить этот список обратно к родительскому объекту, если вам нужно, или что-то еще, но в конце концов поиск кажется более разумным. В конце концов, вы ищете не список связанных объектов, а список изменений, поэтому наличие таблицы изменений кажется разумным способом добиться этого?

person jasonpgignac    schedule 21.07.2010

Эй, у меня была похожая проблема, проверьте это. Если можете, используйте Mongoid или Mongomapper, встроенные версионные документы приятны.

person jpemberthy    schedule 22.07.2010

Спасибо, парни. В конце концов я накатил свое собственное решение, потому что мне действительно нужно было зафиксировать изменения в результатах различных методов, вызываемых для объекта, некоторые из которых включали связанные объекты. Меня не столько интересовали связанные объекты, сколько (например) текстовая строка, сгенерированная в результате просмотра нескольких разных связанных объектов. У меня уже были методы для всего этого, поэтому мне просто нужно было отслеживать изменения в результатах вызова этих методов.

Ни один из плагинов, которые я видел, не мог сделать это просто и эффективно, поэтому я закончил создание таблицы с именем states, которая просто содержит сериализованный хеш с результатами всех этих вызовов методов. Это сохраняется, когда запись изменяется и сохраняется или когда любой из соответствующих связанных объектов изменяется и сохраняется. Затем у меня есть несколько методов для возврата различий между различными сохраненными записями состояния. Это хорошо работает для моих нужд. Спасибо большое за ваш совет в любом случае.

person Max Williams    schedule 23.07.2010