Vanillaxi commented on issue #1128:
URL:
https://github.com/apache/incubator-seata-go/issues/1128#issuecomment-4977559694
在开始 PR 1 前，我这里有几个设计想要确认一下是否合理：
1. 普通 `*sql.Tx` 入口是否允许只保证功能完整、性能自动 fallback
现在计划公开提供 `ExecBatchContext(ctx, db, query, batch)` 和
`ExecBatchInTxContext(ctx, tx, query, batch)` 两个入口。由于标准库 `*sql.Tx`
不提供底层连接访问能力，外部 Tx 入口在无法使用驱动 native batch 时会自动走 semantic backend，但两种入口保持完全相同的 AT
正确性和事务语义
2. Batch API 的位置
* 现在计划是放在 `pkg/datasource/sql` 包下，`pkg/datasource/sql/batch.go `
`pkg/datasource/sql/batch_backend.go ` `pkg/datasource/sql/batch_semantic.go`
,这样改动少，不会产生循环依赖，后续 pgx/MySQL backend 接入方便。不过这样公共 API 和底层代理实现会混在一起，而且用户需要把
seata-go 的 `sql` 包起别名
* 另一个方案是核心放在 `pkg/datasource/sql`，额外提供 facade
内部核心：`pkg/datasource/sql` 对外facade ：`pkg/datasource/sql/batch`
，调用方式：`batch.ExecContext(ctx, db, query, args)` ，这样对外API会更清晰，但是会增加一层封装，容易产生生产依赖
3. 事务所有权语义的设计是否合理
对于传入已有 `*sql.Tx` 的入口，现在我规定的是batch 成功时事务继续由调用者管理；任意 item 失败时 batch API 直接
rollback 整个事务，调用者不能继续使用该 Tx。这样可以避免部分业务修改和 AT 镜像残留。
4. 现在计划是 PR 1 以 seata-go 显式 Batch API 作为正式入口，ORM 可以通过 adapter 或事务回调调用该
API；由于不同 ORM 的 batch 实现可能是循环 Exec、多行 SQL 或驱动私有接口，通用代理层无法可靠推断 batch 边界，所以本 Issue
不计划透明拦截所有 ORM 私有 batch 方法
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
