У меня есть требование, чтобы некоторые изменения атрибутов в записях не отражались в пользовательском интерфейсе до тех пор, пока эти изменения не будут утверждены.Кроме того, если в запись approved
внесено изменение, пользователю будет представлена запись, существующая до approval
.
Моя первая попытка ...
должен был перейти к плагину управления версиями, например paper_trail
, acts_as_audited
и т. Д., И добавить атрибут approved
к их модели версии.Это не только даст мне возможность «откатиться» по версиям записи, но и ДОЛЖНО позволить мне различать, была ли версия утверждена или нет.
Я работал над этим чередойподумал некоторое время, и проблема, с которой я продолжаю сталкиваться, находится на стороне пользователя.То есть как я могу запросить коллекцию approved
записей?Я мог (и пытался) написать несколько вспомогательных методов, которые получают коллекцию записей, а затем перебирают их, чтобы найти "одобренную" версию записи.Моя основная проблема заключается в том, насколько быстро может увеличиться число обращений к базе данных.Моя следующая попытка состояла в следующем:
Version.
where(:item_type => MyModel.name, :approved => true).
group(:item_type).collect do |v|
# like the 'reify' method of paper_trail
v.some_method_that_converts_the_version_to_a_record
end
Таким образом, предполагая, что вызов some_method...
не попадает в базу данных, мы получаем данные, которые нам интересны. ОсновныеПроблема, с которой я столкнулся при использовании этого метода, заключается в том, что я не могу использовать этот «искатель» в качестве области видимости.Таким образом, я не могу добавить дополнительные области к этому поиску, чтобы сузить мои результаты далее.Например, мои записи могут также иметь область действия cool
, которая показывает только записи, где :cool => true
.В идеале я хотел бы посмотреть на свои записи как MyModel.approved.cool
, но здесь, я думаю, мне нужно было бы получить мою коллекцию утвержденных моделей, а затем просмотреть их для cool
, что в итоге привело бы к наименьшему количествузаписей, инициализированных в памяти без причины.
Моя следующая попытка ...
включала создание специального типа «ожидающих записей», которые в основном помогают «потенциальным» изменениямк записи.Таким образом, на стороне пользователя вы будете искать все, что хотите, как обычно.Всякий раз, когда ожидающая запись apply!
(ed), она просто вносит эти изменения в реальную запись, и все хорошо ... За исключением , примерно через 30 минут, я понимаю, что все сломается, если "Администратор "хочет вернуться и внести свой вклад в его изменения, прежде чем одобрить его.Я полагаю, что мой единственный вариант:
Заставить администратора одобрить все изменения, прежде чем вносить дополнительные (которые не пройдут хорошо ... и не должны).
Попробуйте прочитать изменения из модели «ожидающая запись» и применить их к существующей записи без сохранения.Что-то в этой идее не совсем звучит «правильно».
Я бы обожала чей-то вклад в эту проблему.Я боролся с этим в течение некоторого времени, и я просто не могу найти способ, который кажется правильным.Мне нравится жить по мантре «если тебе трудно обдумать это, ты, вероятно, делаешь это неправильно».
И это бьет меня по хвосту ...