scvzerng

 --- 这是初始内存 快速点击几十次后手动gc下如下图  --- ## 可以看出有内存泄漏情况，虽然正常来说menu这么操作很离谱基本上不会

我看了demo里面快100列了，这个虚拟表格没做完整没有横向虚拟只有纵向的也就是说你显示30条数据的话要渲染30*100的单元格列一多就卡顿

其实代码里面有预留相关的逻辑和接口的，动手能力强自己改改就行了

> 完蛋，都没办法解决这个问题了吗。。。我正卡的没办法来找方案 别指望了 试试ag-grid社区版基本够用了 性能很好

```kotlin val updateResult = sqlClient.filters { setBehavior(LogicalDeletedBehavior.IGNORED) }.saveEntities(organizations.map { it.copy { deleteAt = null departments().map { department -> department.copy { deleteAt = null employees().map { employee -> employee.copy { deleteAt...

> 逻辑删除恢复，智能对在简单场景有效，在复杂场景下回导致问题，以postgres为例 > > ``` > CREATE UNIQUE INDEX index_name ON bool(name) > WHERE deleted_millis 0 > ``` > > 则是一条条件唯一性约束，如果数据没有被删除，name必须唯一；否则，既往不咎。删除恢复会导致更多的问题。 > > 因此，逻辑删除的恢复是一个具体情况具体分析的运维行为，无法一刀切地通过框架统一支持。 > > 如果业务上存在可恢复操作，更应该是一个启用/禁用字段和过滤器配合，而不应该直接用逻辑删除来实现 感谢耐心回复

这个好像有两个问题 1. order by 如果有多个他目前只会取第一个 2. 多表关联的时候关联表的order by 字段会被优化掉,所以以下案例 orderProduct.product.name 字段会被优化掉 order by 截取无效 比如一下查询 ```kotlin List page = sqlClients.createQuery(T) .where(T.status().eq("FINISH")) .where(T.orderProducts(op -> op.id().ge(0L))) .where(T.orderProducts(op -> op.product().name().like("%钢%"))) .orderBy(T.asTableEx().orderProducts().id(), T.asTableEx().orderProducts().product().name()) .select(...