Bio-OS 开源开放大赛 T4：Bio-OS 流程规范扩展 - Bio-OS 支持 Nextflow 工作流语言

[a2htray]

have fun，good game.

[CLAassistant]

All committers have signed the CLA.

[yuanminhui]

Awesome work!!

[jixinchi]

file changes里面有一部分代码与此功能无关，例如bioctl里面的export部分，是否可以通过rebase避免？另外，应该把pr提到main分支。PTAL @yifanchen90

[jixinchi]

需要统一注意的是，golang项目的import通常需要分三部分，标准库、第三方库、本repo的其他package，各部分之间有空行

[a2htray]

Thanks to @ealyn and @jixinchi，I will address said issues within the week.

[a2htray]

file changes里面有一部分代码与此功能无关，例如bioctl里面的export部分，是否可以通过rebase避免？另外，应该把pr提到main分支。PTAL @yifanchen90

已经将合并分支修改为 main 分支。

[jixinchi]

整体上，我认为submission和run实体里面都不需要有语言类型，因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选，可以在interface和application层做处理，再在persistence层用sql join工作流的表之后再where过滤。

[a2htray]

需要统一注意的是，golang项目的import通常需要分三部分，标准库、第三方库、本repo的其他package，各部分之间有空行

包导入顺序已修改。

[a2htray]

整体上，我认为submission和run实体里面都不需要有语言类型，因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选，可以在interface和application层做处理，再在persistence层用sql join工作流的表之后再where过滤。

在 Submission 和 Run 表中加入语言类型，确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能，如果按 JOIN 的逻辑，要实现 Run 表的过滤，就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表，4 个表关联查询。通常 3 表关联就需要被避免了，4 表关联也不被采用了。看有没有更好的解决方案，既能实现过滤，又能减少表关联查询。

[a2htray]

目前，PR 中反馈的前端问题已经做了修改，后端功能设计中仍有较多内容需要改进，主要包括：

1. Submission 和 Run 实现中是否应该出现 Language/WorkflowType 字段
2. wes.Client 的实现调整

[jixinchi]

整体上，我认为submission和run实体里面都不需要有语言类型，因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选，可以在interface和application层做处理，再在persistence层用sql join工作流的表之后再where过滤。

在 Submission 和 Run 表中加入语言类型，确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能，如果按 JOIN 的逻辑，要实现 Run 表的过滤，就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表，4 个表关联查询。通常 3 表关联就需要被避免了，4 表关联也不被采用了。看有没有更好的解决方案，既能实现过滤，又能减少表关联查询。

为什么需要对Submission和Run进行语言类型的筛选呢？

[a2htray]

整体上，我认为submission和run实体里面都不需要有语言类型，因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选，可以在interface和application层做处理，再在persistence层用sql join工作流的表之后再where过滤。

在 Submission 和 Run 表中加入语言类型，确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能，如果按 JOIN 的逻辑，要实现 Run 表的过滤，就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表，4 个表关联查询。通常 3 表关联就需要被避免了，4 表关联也不被采用了。看有没有更好的解决方案，既能实现过滤，又能减少表关联查询。

为什么需要对Submission和Run进行语言类型的筛选呢？

主要是希望围绕工作流作一些功能扩展，就做了过滤，倒也不是说一定要对 Submission 和 Run 表做过滤。

[jixinchi]

整体上，我认为submission和run实体里面都不需要有语言类型，因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选，可以在interface和application层做处理，再在persistence层用sql join工作流的表之后再where过滤。

在 Submission 和 Run 表中加入语言类型，确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能，如果按 JOIN 的逻辑，要实现 Run 表的过滤，就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表，4 个表关联查询。通常 3 表关联就需要被避免了，4 表关联也不被采用了。看有没有更好的解决方案，既能实现过滤，又能减少表关联查询。

为什么需要对Submission和Run进行语言类型的筛选呢？

主要是希望围绕工作流作一些功能扩展，就做了过滤，倒也不是说一定要对 Submission 和 Run 表做过滤。

list runs必填submission id，所以完全没必要做类型过滤；list submissions可选workflow id，可以针对单个工作流过滤，应该也不需要针对工作流类型进行过滤

[a2htray]

整体上，我认为submission和run实体里面都不需要有语言类型，因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选，可以在interface和application层做处理，再在persistence层用sql join工作流的表之后再where过滤。

在 Submission 和 Run 表中加入语言类型，确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能，如果按 JOIN 的逻辑，要实现 Run 表的过滤，就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表，4 个表关联查询。通常 3 表关联就需要被避免了，4 表关联也不被采用了。看有没有更好的解决方案，既能实现过滤，又能减少表关联查询。

为什么需要对Submission和Run进行语言类型的筛选呢？

主要是希望围绕工作流作一些功能扩展，就做了过滤，倒也不是说一定要对 Submission 和 Run 表做过滤。

list runs必填submission id，所以完全没必要做类型过滤；list submissions可选workflow id，可以针对单个工作流过滤，应该也不需要针对工作流类型进行过滤

好的，修改后会重新提交。

[shaodongyan]

Real good work