proposal: ezorm-v2: generate orm-code according to user provided sql. about ezorm

[hackerzgz]

1. in / ret 作为模版中定义的入参和出参，名字是否能够对应起来，比如：input / output 等，可能会更直观。
2. 如果用户定义的函数名称与 orm 中默认生成模版的函数名称发生了冲突，是如何进行处理？
3. 自定义 SQL 复用是否支持存储过程？在存储过程中，@ 是关键字，用于定义、使用变量，可能会跟自定义 SQL 模版的定义变量语法冲突。

[scbizu]

1. 通过在gen的时候去连接数据库拿到数据表结构并不好，这要求我们CI必须连接到数据库，我们线上数据库是没有开外网访问的，线上代码编译时应该连接哪个数据库 ？所以我觉得v2一开始没有必要开这个口子，或者之后有需求再做。 原来ezorm sqlserver driver的这种方式我觉得不是好的实践
2. 之前不管ezorm还是redis-orm对JOIN支持差是因为不鼓励开发滥用多表关联去写业务，但是我想在v2加这个需求是因为，确实在代码充斥着一大段一大段的raw query很难维护(SQL Lint无法检查，也没有高亮)，也很容易写出性能问题。通过raw query生成Exec/Query大方向我觉得是没错的，我之前的想法是我们会有个subfolder可以支持yaml中的section(db table/db field)定义，比如这个subfolder叫做queries，里面会包括一部分.sql文件，这些.sql文件可以用 Go Template build成真正的SQL Query(这很重要，我们可以集成到我们的自动化工具里面，在提交发布单时，也给DBA提交SQL Review Ticket)。

  User:
    - Id: int64
    - Name: string
    - Phone: string
    - Text: nullstring

## before parse
SELECT {{ .User.Id }} FROM {{ .User }} INNER JOIN {{ .Blog }} ON {{ .User.Id }} = {{ .Blog.UserId }} WHERE {{ .User.Id }} = 1;
## after parse
SELECT oper_user.id FROM oper_user INNER JOIN oper_blog ON oper_user.id = oper_blog.user_id WHERE oper_user.id = 1;

3. 虽然v2可以引入Break Changes，但是我还是希望主体YAML结构不要变化那么大，不然会对我们的迁移造成很大的麻烦。或者可以在yaml引入版本号: orm-version: v0.2.0

---

以上，对于你有兴趣/有勇气接起这个锅深感佩服，加油 🤟

[fioncat]

@scbizu
因为mysql的设计范式问题，所以大部分业务设计表都会做很多拆分，所以我觉得JOIN确实没办法避免😐。

我之前的想法也是通过某种方式来引用外部的sql文件，但是这样的话，在看代码的时候，如果要定位某个sql，需要code->yaml->sql这样的链路，开发的时候也需要同时编辑三个文件，是否会对开发效率带来影响？所以我这里的想法是直接把sql语句集成在yaml中，我们后期是否可以通过单独开发Tool来根据yaml生成sql文件来供DBA review？反正既然格式固定，这样的Tool开发起来也很轻松。至于SQL Lint，也许我们有余力可以用Editer Plugin来支持🤣？

关于Break Changes，主要是我觉得这种复杂语句以业务方法来做聚合比较好，所以没有放在db table/db field里面，而是单独作为独立的方法来使用，而且这样用户可以非常自由的传入一些额外的参数。

[fioncat]

@hackerzgz

1. 确实可以，参数名称可以再考虑。
2. 可以通过生成器报错，或是单独使用一个namespace，让用户通过model.namespace.method这样的方式来调用。
3. 所有占位符的解析，都是在generate阶段就完成了，最终生成的sql语句是没有这些占位符的，因此我们只需要巧妙设计生成器，让其只识别@{name}这样的格式，不误判@name即可。

[scbizu]

我之前的想法也是通过某种方式来引用外部的sql文件，但是这样的话，在看代码的时候，如果要定位某个sql，需要code->yaml->sql这样的链路，开发的时候也需要同时编辑三个文件，是否会对开发效率带来影响？

---

不是的，开发只需要维护SQL模板文件，其它的是由工具自己生成的，类似现在的yaml。这些SQL依旧会被生成到 gen文件中，加上// DO NOT EDIT，gen的文件是不能编辑的，SQL模版文件是 Source of truth 。

我们后期是否可以通过单独开发Tool来根据yaml生成sql文件来供DBA review？

---

比较好的做法可能是我们开发和DBA Review时的生成工具是同一套。

SQL Lint，也许我们有余力可以用Editer Plugin来支持

---

既然SQL Template的做法可以被原始的lint支持到， 那我们为什么还要重新写轮子呢 ？

这样用户可以非常自由的传入一些额外的参数

---

不能太自由，会给维护带来很多不必要的麻烦 XD

[fioncat]

已经合入v2分支