Приложение Rails 3.2 - Должен ли я использовать гем управления версиями (paper_trail или vestal_versions) или обработать его вручную?

Мой вопрос: я должен свернуть свою собственную версионность модели или использовать одну из версий, которая уже существует? Если я должен использовать драгоценный камень, какой из них лучше всего подходит для этого приложения?

Информация о моем приложении

Мое приложение представляет собой простое приложение Checklist. Есть контрольные списки и задания, и я отслеживаю ответы пользователей с помощью ответов и отправлений. Ответ сообщает мне, что сказал пользователь ("Готово", с пометкой "Нам нужно больше швабр."), А в сообщении указывается, когда этот конкретный контрольный список был заполнен (потому что может быть много представлений и наборов ответов для данного контрольный список). Я покажу свои ассоциации ниже, на случай, если это поможет.

#checklist.rb
class Checklist < ActiveRecord::Base
  has_many :jobs, :through => :checklists_jobs
  has_many :submissions
end

#job.rb
class Job < ActiveRecord::Base
  has_many :checklists, :through => :checklists_jobs
  has_many :responses
end

#response.rb
class Response < ActiveRecord::Base
  belongs_to :job
  belongs_to :submission
  belongs_to :user
end

#submission.rb
class Submission < ActiveRecord::Base
  belongs_to :user
  belongs_to :checklist
  has_many :responses
end

Что я пытаюсь сделать с версионированием

Что я хочу сделать, так это записывать ответы пользователей на задания в контрольных списках. Но я хочу убедиться, что смогу воспроизвести исходный контрольный список (с информацией об ответах), если контрольный список изменится. Например, я хочу убедиться, что могу ответить на этот вопрос для всех предыдущих версий контрольного списка:

"Как выглядел контрольный список и каковы были ответы три вторника назад?"

Я не хочу потерять ответ на этот вопрос, если я изменю контрольный список или любое из его заданий.

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

Должен ли я использовать драгоценный камень или свернуть свой собственный?

Я пытаюсь решить, должен ли я просто свернуть свое собственное (написать код для увеличения версии, указать все на версию и сохранить предыдущую версию) или использовать существующее решение. Два лучших решения - это paper_trail и vestal_versions. У меня недостаточно очков репутации, чтобы опубликовать более двух ссылок, поэтому я буду ссылаться на каждый из Railscast для гемов (который, если хотите, приведет вас к самому гему). Railscast 255 Undo с paper_trail и http://railscasts.com/episodes/177-model-versioning - 177 использует vestal_versions.

Плюсы катаются мои:

  • Мне нужно отчитываться по всем историческим данным путем восстановления контрольных списков и их ответов. Это главная особенность приложения. Кажется, что это будет сложно с драгоценными камнями, которые я упомянул.
  • Я буду в состоянии сообщить о группах версий ("Я хочу видеть все ответы для любой версии этого задания"). Это кажется легким в этом смысле.

Минусы для прокатки своих:

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

Это кажется важным, потому что все, что я решу, я застряну. Я не думаю, что будет легко переключиться с одного метода на другой позже.

Источник

2 ответа

Решение

По моему опыту, когда вы задаете вопрос о том, как создать собственное решение, а не использовать стороннее решение, ответ почти всегда звучит так: "Сверните свое". Мало того, что вы можете сделать именно то, что вы хотите с точки зрения функциональности, вы не обязаны другому разработчику:

  1. Исправьте свои ошибки
  2. Поддержка последних обновлений рельсов / обновлений ruby ​​и т. Д.
  3. Не конфликтуйте каким-либо образом с вашим приложением тонкими способами, к которым вы не можете обратиться (требуются разные версии зависимых гемов).

Я говорю, что если у вас есть способность, вы должны тратить время и писать именно то, что вы хотите. Это окупится через два года.

Источник

Используйте PaperTrail, и не катите свое собственное решение. Я категорически не согласен с ответом Ричарда. PaperTrail - очень активный проект, многие люди вносят свой вклад в исправление ошибок, поддерживают последние версии Rails и Ruby и обрабатывают конфликты с драгоценными камнями.

Если вам не нравится, как PaperTrail что-то делает, вам следует его раскошелиться и изменить это поведение. Если это общее улучшение, отправьте запрос на извлечение, чтобы мы могли получить выгоду от вашей работы. Не переписывайте его с нуля, потому что у вас нет ретроспективных ошибок и крайних случаев, через которые уже прошли коммиттеры PaperTrail.

Источник
Другие вопросы по тегам