Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 25

Знаете, что из всего этого следует? Что в отличие от хард, soft deletion - это бизнес-операция, а не техническая операция хранилища. И решать ее нужно, соответственно, на бизнес-, а не на техническом уровне. С той же статьей, например, комментарии к софтово-удаленной статье можно таким же образом софтово-удалить.

Всего голосов 14: ↑14 и ↓0+14

100% согласен

Всего голосов 8: ↑8 и ↓0+8

С той же статьей, например, комментарии к софтово-удаленной статье можно таким же образом софтово-удалить.

Если потом восстановить софтово-удаленную статью, то не получится отличить комментарии, которые софтово-удалены вместе со статьей от комментариев, которые софтово-удалены сами по себе по кнопке "удалить комментарий".

Всего голосов 1: ↑1 и ↓0+1

...значит, нужен гипер-флаг, говорящий о том, что удаление прилетело сверху, и computed-колонка, которая объединяет эти флаги по ИЛИ )

Всего голосов 1: ↑1 и ↓0+1

значит, нужен гипер-флаг,

Конечно, нужен. Лишь подтверждение тому, что у задачи отсутствует чисто-техническое решение, как вы верно заметили в своём изначальном комментарии.

Комментарий пока не оценивали0

Зачем удалять комментарии каскадом не пойму. Статья удалена софтово. К ней есть джойны у комментариев. Состояние комментариев однозначно (видим, не видим потому что удалена статья, не видим потому что удален комментарий), зачем его портить? По какому хочешь критерию по такому и тащишь.

Всего голосов 1: ↑1 и ↓0+1

Более того, если их удалять, то

нужен гипер-флаг

Оверинженер в действии :)

Вообще, с помощью софтделишена решать задачу data recovery идея не очень. Ведь нужно знать контекст удаления. Плюс, потом базу будем мигрировать вместе с удаленными сущностиями, а ведь иногда поля могут становиться обязательными... И чем заполнять удаленные данные? Де-факто мы их трогать вообще после удаления не должны... Вобщем одни минусы. Почему знаю, я так делал :). Потом переписал на жесткое удаление с сохранинием фактически удаляемых данных в монгу + отедльная логика восстановления в зависимости от версии модели.

Всего голосов 3: ↑3 и ↓0+3

Если пользоваться мягким удалением, то для многих может быть неожиданностью, что не работат стандартные хуки связанные с delete - preRemove/postRemove, при это в postUpdate нельзя понять контекст что запись была мягко удалена.

Всего голосов 5: ↑4 и ↓1+3

Если у вас разработка на триггерах - ну что ж, вы, самураи, сами выбрали этот путь.

Всего голосов 6: ↑6 и ↓0+6

не работат стандартные хуки связанные с delete

Как и CascadeType.REMOVE

Всего голосов 2: ↑2 и ↓0+2

В 99% soft-delete не нужен. От него геморроя больше, чем профита.

Хочется иметь возможность восстановить удалённые записи? Envers в помощь. Да, придётся сделать дополнительные приседания, но это хоть как-то управляемо и настраиваемо.

Всего голосов 1: ↑1 и ↓0+1

Есть два типа людей: те, которые думают, что soft-delete - это генианльно и те, которые его уже выпилили из проекта.

Всего голосов 4: ↑4 и ↓0+4

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

Всего голосов 5: ↑5 и ↓0+5

Действительно, бизнес-функции стоит называть по бизнесовому :)

Всего голосов 4: ↑4 и ↓0+4

Для @Fetch(FetchMode.JOIN) @ManyToOne(fetch = FetchType.EAGER) Фильтрация @Where включается, если в join добавлено условие фильтрации @JoinColumnOrFormula по полю, не являющемуся id.

Пример:

модель

@Entity
@Table(name = "post_reference")
public class PostEagerJoinReference {

    @Id
    private Long id;

    @Fetch(FetchMode.JOIN)
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumnOrFormula(column = @JoinColumn(name = "post_id", referencedColumnName = "id"))
    @JoinColumnOrFormula(formula = @JoinFormula(value = "any", referencedColumnName = "title"))
    private Post post;
}

@Entity
@Table(name = "post")
@Where(clause = "deleted = false")
public class Post implements Serializable {

    @Id
    private Long id;

    @Column(name = "title")
    private String title;

    @Column(name = "deleted")
    private boolean deleted = false;
}

на запрос

entityManager.find(PostEagerJoinReference.class, 1L);

генерируется запрос:

select
    posteagerj0_.id as id1_1_0_,
    posteagerj0_.post_id as post_id2_1_0_,
    any as formula2_0_,
    post1_.id as id1_0_1_,
    post1_.deleted as deleted2_0_1_,
    post1_.title as title3_0_1_
from
    post_reference posteagerj0_ 
left outer join
    post post1_ 
        on posteagerj0_.post_id=post1_.id 
        and any=post1_.title 
        and (
            post1_.deleted = false
        )  
where
    posteagerj0_.id=?

В качестве поля не являющимся id можно использовать delete = true, тогда фильтр `deleted = false` на JOIN задвоится.

Кстати еще это приведет вот к такому багу https://hibernate.atlassian.net/browse/HHH-7668, который решается добавлением на сущность implements Serializable.

Всего голосов 3: ↑3 и ↓0+3

Спасибо! Но это не отменяет того, что поведение не должно зависить от типа FetchType. А потом в Spring Data кто-то определяет EntityGraph и все снова летит к чертям...

Всего голосов 1: ↑1 и ↓0+1

Да тут все плохо, но с этим уже как-то можно жить с hibernate. Мне в проекте по другой причине нужно было добавить дефолтную фильтрацию. Пробовал @Where, @Filter, @Loader. И везде свои дыры и баги.

Комментарий пока не оценивали0

@Filter вообще отлично работает взде, кроме... кэша :).

Всего голосов 2: ↑2 и ↓0+2

Да и он на фетчинг никак не влияет, только на запросы. Полезная штука)

Всего голосов 2: ↑2 и ↓0+2

За все время так и не нашел аргументов за ленивое удаление, особенно если оно настроено для всего подряд. За пять лет пригодилось может один или два раза и то для дебага.

Всего голосов 1: ↑1 и ↓0+1
Мягкое удаление делаем ручками. Часто вместо него можно сделать галочку Активный, а на странице списка объектов — фильтр, который по умолчанию показывает только активные. Если юзер по ошибке удалил — он может сам восстановить объект (вернуть галочку), не нужно просить запускать SQL апдейт для этого. И можно отредактировать уже «удалённый» объект при необходимости.
Всего голосов 2: ↑2 и ↓0+2

А как это выглядит в спрингдате?

Комментарий пока не оценивали0

Везде приходится писать @Query и перегружать стандартные методы. По другому не выйдет.

Всего голосов 2: ↑2 и ↓0+2
Спрингдату не используем, везде вручную добавляем условия по active = true
Всего голосов 2: ↑2 и ↓0+2

Самый неочевидный факт в мягком удалении, это то зачем оно нужно. Часто под мягким удалением подразумемвают замену системной delete операции. По этому и появляется нужда в системном подходе к решению. На самом же деле это не системная, а бизнес операция. Спустить бизнес уровень на системный всегда чревато серьезными последствиями. Особенно такими что многние подходы и библиотеки станут неприменимы.

Всего голосов 2: ↑2 и ↓0+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr