Должно ли is_paranoid быть встроенным в Rails?

Question

Или, по-другому, есть ли причина не использовать его на всех моих моделях?

Некоторого фон: is_paranoid драгоценный камень, который делает звонки на destroy установленных в deleted_at метку времени, а не удалять строку (и вызовы find исключить строки с непустыми deleted_at с).

Я нашел эту функцию настолько полезной, что я начинаю включать ее в каждую модель - трудно удалить записи просто страшно. Есть ли причина, по которой это плохо? Если эта функция включена по умолчанию в Rails?

Answer 1

Ruby не для трусов, которые боятся своего кода!

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

Другое дело, что ваш подход к дизайну базы данных является своеобразным рубином. Вы будете страдать от необходимости обрабатывать все эти вещи deleted_At, когда вам приходится писать более сложные запросы к вашим таблицам, чем просто finds. И вы, безусловно, будете, когда DB вашего приложения занимает много места, поэтому вам придется заменить красивый и блестящий код ruby ​​на хакерские SQL-запросы. Вы можете захотеть отбросить этот столбец, но ... oops - вы уже использовали логику deleted_at, и вам придется переписать большие части вашего приложения. Попался.

И на последнем месте, на самом деле кажется естественным, когда вещи исчезают при удалении. И весь смысл моделирования заключается в том, что модели пытаются выразить на машиносчитываемых терминах то, что происходит там. По умолчанию вы удаляете запись, и она проходит вечно. И только причина deleted_at может быть естественной, когда запись должна быть позже восстановлена ​​или должна помешать аналогичной записи путать с исходной (таблица для пользователей, скорее всего, место, которое вы хотите использовать). Но в большинстве моделей это просто паранойя.

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

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

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

(Это влияние оказало влияние на ценные замечания railsninja).

Answer 2

@Pavel Shved

Прошу прощения, но что? Рубин не для трусов, боящихся кода? Это может быть одна из самых смешных вещей, которые я когда-либо слышал. Конечно, в таблице соединений вы хотите удалить записи, но как насчет модели объединения, она может пройти много, а может и нет.

В бизнес-приложениях часто имеет смысл не просто удалять вещи, а пользователи делают ошибки, МНОГО.

Большая часть вашего ответа, Павел, - это своего рода трюк. Нет никакого стыда в использовании SQL, где вам нужно, и как использование deleted_at вызывает этот массивный рефакторинг, я в затруднении по этому поводу.

@Horace Я не думаю, что is_paranoid должен быть в ядре, не всем это нужно. Это фантастический камень, хотя я использую его в своих рабочих приложениях, и он отлично работает. Я также вполне уверен, что он не заставил меня прибегать к sql, когда мне это не нужно, и я не вижу большого рефакторинга в моем будущем из-за его присутствия. Используйте его, когда вам это нужно, но это должен быть камень.