ManyToMany 多对多的按一方ID配置逻辑删除时，执行时，目前的行为是中间表的数据未删除掉 about jimmer

[qinkangdeid]

ManyToMany 应该不需要配@OnDissociate吧 因为我配置了编译报错

[qinkangdeid]

对比官方示例中的 测试如下：

未开启逻辑删除：

1. 虚拟外键：主表删除OK 中间表删除OK
2. 真外键：主表删除OK 中间表删除OK

开启逻辑删除：

1. 虚拟外键：主表删除OK 中间表未删除
2. 真外键：主表删除OK 中间表未删除

[babyfish-ct]

我以为是删除一侧，伪外键中间表记录不能清理（之前一个版本已经修改了这个问题）

现在，是逻辑删除的问题，那就不光是中间表记录是否保留的问题了，子表外建也存在是否set null甚至连子表记录也一并删除的问题。

如果逻辑删除一条记录，既要删除中间表，又要清理子表外建甚至连子表记录也删除。那么，除了当前记录是hide还是delete外，更多的对周边的扩散操作和物理删除无差异，确定？

[qinkangdeid]

这个issue提出的情况是:
因为当时中表无法添加逻辑删除字段 去处理逻辑删除的问题
所以第一反应是中间表的数据要删掉 (现在是未删除)
但后面与其他用户讨论之后，发现:
这是 一对数据 如果主表的数据处理的逻辑删除， 中间表无论是物理删除或者未删除 都是能导致数据不一致的情况。虽然逻辑删除的数据在系统层面来说已经不存在。但是免不了需要查询。也许是为了撕逼。也许是为了把数据恢复

目前感觉中间表可以加逻辑字段的话是最简单有效的方式

在这里说也希望能够有更多的用户来参与讨论或者说注意这个问题

[babyfish-ct]

Resolved, @jointable now support both logical deletion and physical deletion based on logical deleted of either side.

[qinkangdeid]

根据新版注释来看：

    /**
     * In general, if entities on either side support logical deletion,
     * middle tables should also support logical deletion.
     * Otherwise, error will be raised.
     *
     * <p>
     *     When entity on either side is logically deleted,
     *     the rows of middle tables should be logically deleted too.
     * </p>
     *
     * <p>
     *     However, if you don't want intermediate table records to support soft deletion,
     *     turn this switch on. When an object at either side is logically deleted,
     *     the corresponding middle table records will be physically deleted.
     * </p>
     */
    boolean deletedWhenEndpointIsLogicallyDeleted() default false;

我试了一下 默认deletedWhenEndpointIsLogicallyDeleted不配置 也就是 照旧配置：

    @ManyToMany
    @JoinTable(
        name = "plan_menu_mapping",
        joinColumns = [JoinColumn(name = "plan_id", foreignKeyType = ForeignKeyType.FAKE)],
        inverseColumns = [JoinColumn(name = "menu_id", foreignKeyType = ForeignKeyType.FAKE)],

    )
    val menus: List<Menu>

测试的结果行为和以前一致

当添加 deletedWhenEndpointIsLogicallyDeleted=true时 会先 物理删除 中间表数据 在逻辑删除 主表数据：

    @ManyToMany
    @JoinTable(
        name = "tenant_plan_menu_mapping",
        joinColumns = [JoinColumn(name = "tenant_plan_id", foreignKeyType = ForeignKeyType.REAL)],
        inverseColumns = [JoinColumn(name = "menu_id", foreignKeyType = ForeignKeyType.REAL)],
        deletedWhenEndpointIsLogicallyDeleted = true
    )
    val menus: List<Menu>

2024-02-22 18:12:30.651  INFO 14029 --- [  XNIO-1 task-1] o.b.jimmer.sql.runtime.ExecutorForLog    : Execute SQL===>
Purpose: DELETE
SQL: delete from tenant_plan_menu_mapping
where
    tenant_plan_id = 7149655580733345793
Affected row count: 2
JDBC response status: success
Time cost: 35ms
<===Execute SQL
2024-02-22 18:12:30.678  INFO 14029 --- [  XNIO-1 task-1] o.b.jimmer.sql.runtime.ExecutorForLog    : Execute SQL===>
Purpose: DELETE
SQL: update tenant_plan set deleted = 1
where
    id = 7149655580733345793
Affected row count: 1
JDBC response status: success
Time cost: 25ms
<===Execute SQL

我这里有一个疑问：当 deletedWhenEndpointIsLogicallyDeleted为默认值false时，中间表的逻辑删除的意思是不处理中间表数据吗？中间表要不要添加逻辑删除字段？ 我看注释的意思的理解是：

1. 主表有逻辑删除字段 配置好后 支持delete 转 update 逻辑删除 中间表没有逻辑删除自动不管 不执行(与之前一致)

2. 主表有逻辑删除字段 当中间表也添加了逻辑删除字段 与主表行为一致 支持delete 转 update 逻辑删除
   这个点我测试了下 往中间表也添加逻辑删除字段 但是结果与1一致 中间表在建模关系中是“不存在”的 是否加不加逻辑删除字段 都找不到这个字段？？？所以不处理 还是我理解的有误？

3. 主表有逻辑删除字段 主表执行deleted转update 但配置 deletedWhenEndpointIsLogicallyDeleted=true 不管中间表有没有添加逻辑删除字段