Closed a2htray closed 9 months ago
Awesome work!!
file changes里面有一部分代码与此功能无关,例如bioctl里面的export部分,是否可以通过rebase避免?另外,应该把pr提到main分支。PTAL @yifanchen90
需要统一注意的是,golang项目的import通常需要分三部分,标准库、第三方库、本repo的其他package,各部分之间有空行
Thanks to @ealyn and @jixinchi,I will address said issues within the week.
file changes里面有一部分代码与此功能无关,例如bioctl里面的export部分,是否可以通过rebase避免?另外,应该把pr提到main分支。PTAL @yifanchen90
已经将合并分支修改为 main 分支。
整体上,我认为submission和run实体里面都不需要有语言类型,因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选,可以在interface和application层做处理,再在persistence层用sql join工作流的表之后再where过滤。
需要统一注意的是,golang项目的import通常需要分三部分,标准库、第三方库、本repo的其他package,各部分之间有空行
包导入顺序已修改。
整体上,我认为submission和run实体里面都不需要有语言类型,因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选,可以在interface和application层做处理,再在persistence层用sql join工作流的表之后再where过滤。
在 Submission 和 Run 表中加入语言类型,确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能,如果按 JOIN 的逻辑,要实现 Run 表的过滤,就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表,4 个表关联查询。通常 3 表关联就需要被避免了,4 表关联也不被采用了。看有没有更好的解决方案,既能实现过滤,又能减少表关联查询。
目前,PR 中反馈的前端问题已经做了修改,后端功能设计中仍有较多内容需要改进,主要包括:
整体上,我认为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实体里面都不需要有语言类型,因为这些是属于工作流的属性。假如希望在页面上展示语言类型以及做语言类型的筛选,可以在interface和application层做处理,再在persistence层用sql join工作流的表之后再where过滤。
在 Submission 和 Run 表中加入语言类型,确实与 DDD 领域实体的设计思想不符。当时主要考虑是为了加过滤功能,如果按 JOIN 的逻辑,要实现 Run 表的过滤,就需要 Run 表 join Submission 表、Workflow 表、WorkflowVersion 表,4 个表关联查询。通常 3 表关联就需要被避免了,4 表关联也不被采用了。看有没有更好的解决方案,既能实现过滤,又能减少表关联查询。
为什么需要对Submission和Run进行语言类型的筛选呢?
主要是希望围绕工作流作一些功能扩展,就做了过滤,倒也不是说一定要对 Submission 和 Run 表做过滤。
整体上,我认为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,可以针对单个工作流过滤,应该也不需要针对工作流类型进行过滤
整体上,我认为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,可以针对单个工作流过滤,应该也不需要针对工作流类型进行过滤
好的,修改后会重新提交。
Real good work
have fun,good game.