«Удаление» объектов в Django

[hatman]

Момент про замедление работы запросов, когда в базе куча хайд-объектов — не есть хорошо. Не пробовали по какому-то тайм-ауту, выгружать джобой данные в какую-то резервную базу, а из основной делать честный делит в периоды наименьшей активности (скажем 4 утра)?

[mihail777str]

Согласен, что во многих проектах можно сделать честное удаление ночью. Но увы, это не наш случай. В силу специфики проекта мы не имеем периодов низкой активности. Так называемые «чекеры» шлют новые данные ежесекундно.

[hatman]

А если юзер просит удалить данные в рамках GDPR, а у вас по-умолчанию данные хайдятся. какое решение?

[mihail777str]

Над этим вопросом мы тоже думали, только с другой стороны: «Как посмотреть удаленные объекты?». Для подобных целей можно использовать стандартный менеджер, который будет заранее сохранен декоратором под другим атрибутом модели, например all_objects:

# добавить строку в декоратор перед переопределением model_class.objects
# model_class.all_objects = copy.deepcopy(model_class.objects)

Host.objects.values('id')
# SELECT `Hosts`.`id` FROM `Hosts` WHERE NOT (`Hosts`.`is_deleted` = True)
Host.all_objects.values('id')
# SELECT `Hosts`.`id` FROM `Hosts`

# удаление работает должным образом
Host.all_objects.filter(is_deleted=True).first().delete()

[hatman]

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

[mihail777str]

Да, возможно. В комментарии выше я написал, как это сделать.
Через менеджер all_objects можно запустить стандартный delete().

[cb_ein]

Вместо декораторов можно использовать кастомные QuerySet и/или Manager с последующим линкованием к objects. Однако, сама по себе идея оставлять объекты в базе мне кажется весьма сомнительной. Мы в подобной ситуации просто начали запускать удаление чаще, в моменты минимальной нагрузки и маленькими порциями.

[oogl]

Нубский вопрос. А почему бы не засунуть запрос во View и обойтись без декораторов?

[mihail777str]

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

[oogl]

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

[mihail777str]

Присутствие в блоге Django и рядом стоящие слова «View» и «декораторы» заставили меня думать про View в рамках MVC. Теперь понял, что вопрос уровня БД.

Да, создание представлений таблиц с фильтрами — интересное решение, которое имеет право на существование, но, как всегда, не без подводных камней:

• когда мы спускаемся на уровень БД, то идем к узконаправленным решениям, что снижает их универсальность;
• нужно помнить, что представления — это все же не таблицы, поэтому как минимум для миграций нужно прописать названия оригинальных таблиц, а это уже изменения в коде. Если погружаться в решение глубже, то нужно изучить, всегда ли будут использоваться индексы, как и при работе с таблицей, и как будут происходить блокировки при записи или обновлении данных;
• поиск всех зависимостей и написание представлений — тоже немалая работа. В нашем случае это решилось предложенным тестом, который сам нашел все зависимости. Можно пойти дальше и сделать так, чтобы декорирование необходимых моделей происходило автоматически при запуске проекта, но мы остановились на более явном определении.

Имхо, данное решение требует дополнительного изучения в силу различий между таблицей и представлением, изучения его универсальности на разных СУБД, и все же требует большего количества времени на внедрение, а в результате будут выполняться все те же фильтры.

[oogl]

Спасибо за ответ.