gaoyan

This feature is not implemented yet, maybe 1.1? or later

@suxinshuo 我提供一下建议 1. 预览只是临时运行使用，不会一直在后台运行，所以mysql压力可以不必考虑， 2. 我认为这个历史功能应该尽他的职责，只是保存执行历史最后几条数据即可，而正在运行的实时数据就不用考虑写入，用户应该在结果页面查看实时数据，所以不存在延迟问题 3. dinky_history目前已经有机制定时删除 4. 我觉得存resource实现成本太大了无论是开发还是用户体验，为了这个功能不值得，而且，从功能设计上讲，resource也不应该服务于这个事情

> 1. 保存执行历史最后几条数据，这个针对批任务比较好处理，实时任务在执行历史中有可能还没有停止，保存数据这个动作的触发时机不好把控，所以说是会有一定的延迟，可以采用 @Zzm0809 提出的方案，加一个获取最新数据的按钮，定时+手动触发更新，读取从本地缓存 ResultPool 都切换成 mysql 中读取，保证数据的一致性 > 2. resource 我从代码看确实不应该去实现执行历史数据存储这个功能，看起来代码都绑定死了上传路径这个东西，基本上就是为资源上传存储服务的，不知道我这个理解对吗，辛苦大佬帮忙解答一下 @gaoyan1998 > 3. 基于上面的回复，采用方案1，我下面画了个流程图，辛苦各位大佬帮忙看一下 > 主要改动如下: > 3.1 SelectResult 增加数据更新时间、持久化时间、是否截断数据字段，用来标识数据是否需要做持久化存储 > 3.2 增加定时扫描、注册监听器、Spring 容器销毁触发数据持久化存储 > > ...

我觉得可以 @Zzm0809 你看看还有啥补充么

mysql表内可以试着取消name唯一约束，这个不影响任务，后续会修复此问题

LGTM

>  我可以实现，做成这种表单可以不 我觉得阔以

hi @ruanwenjun PTAL ,please approval workflows

> Please create an issue and link to it. @gaoyan1998 @SbloodyS Sorry for the missing issue, it has now been created and the title changed

Hi, is there a solution to this problem, now idea still has a big box wrapped around it