github-actions[bot] commented on issue #1128:
URL:
https://github.com/apache/incubator-seata-go/issues/1128#issuecomment-4977560854
> Bot detected the issue body's language is not English, translate it
automatically.
Before we get started with PR 1, here are a few designs I'd like to confirm
make sense:
1. Does the normal `* sql.Tx` entrance allow only functional integrity and
automatic fallback of performance?
It is now planned to publicly provide two entries, `ExecBatchContext
(ctx, db, query, batch)` and `ExecBatchInTxContext (ctx, tx, query,
batch)`.Since the standard library `* sql.Tx` does not provide underlying
connectivity access, external Tx entries automatically go semantic backend when
the driver native batch cannot be used, but the two entries maintain exactly
the same AT correctness and transaction semantics
2. Location of the Batch API* Now the plan is to put it under the
`pkg/datasource/sql` package, `pkg/datasource/sql/batch.go`
`pkg/datasource/sql/batch_backend.go` `pkg/datasource/sql/batch_semantic.go`,
so there are few changes and no circular dependencies, and subsequent pgx/MySQL
backend access is convenient.However, the public API and the underlying proxy
implementation will be mixed, and the user needs to wrap the `sql` of seata-go
with an alias
* Another option is to put the core in `pkg/datasource/sql` and
provide additional facade
Internal core: `pkg/datasource/sql` External facade:
`pkg/datasource/sql/batch`, called by: `batch.ExecContext (ctx, db, query,
args)`, so that the external API will be clearer, but it will add a layer of
encapsulation, which is easy to create production dependencies
3. Is the design of the transaction ownership semantics reasonable?For
incoming entries that already have `* sql.Tx`, I now stipulate that the
transaction continues to be managed by the caller when the batch is successful;
when any item fails, the batch API directly rolls back the entire transaction,
and the caller cannot continue to use the Tx.This avoids some business
modifications and AT image residues.
4. Now the plan is that PR 1 will use the seata-go explicit Batch API as the
formal entrance, and ORM can call this API through adapter or transaction
callback. Since the batch implementation of different ORMs may be loop Exec,
multi-line SQL, or drive private interfaces, the universal proxy layer cannot
reliably infer the batch boundary, so this issue does not plan to transparently
intercept all ORM private batch methods.
--
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]
