To help troubleshoot when conversion is successful as 2waysql but SQL execution error occurs.

Accept user defined type for bind parameters like below.

type MyInt int
type MyStr string

If SQL comments are included, the execution is returned with an error or empty.
I would like to be able to include comments.

Scenario

Log error.

{s: "no parameter that matches the bind value: role"}}

Bind params.

	param := struct {
		UserID   any    `twowaysql:"user_id"`
		role       []any  `twowaysql:"role"`
	}{
		UserID:                   loginId,
		role:                      role,
	}

Because role fields is private then twowaysql shows error message.
At this time, can you issue a help message saying "role may be private"?

An error occurs when line breaks and spaces exist when writing JS source in SQL

error contents

"error":"system_error: db_sql_error: (anonymous)

Error example
error for line breaks and spaces
xxx.sql

/*
    IF 1 == 1
*/

Not Error exapmle
no error for line breaks and tab spaces
xxx.sql

/*
	IF 1 == 1
*/

#contents

go-twowaysql outputs panic when used in goroutine because tagscanner v1.0.2 or below can't be used in goroutines.

What I'd like to do

Update the version of tagscanner and release new version of go-twowaysql.

Improved recover and automatic rollback in the panic

Example

SELECT * FROM t WHERE (col1, col2)  IN ( VALUES (val1a, val2a), (val1b, val2b)) ;

https://stackoverflow.com/questions/69263666/select-where-in-multiple-pairs-postgresql

Design Plan

SELECT * FROM t WHERE (col1, col2)  IN ( VALUES /*pair*/('aa', 'bb'),) ;

bind parameters is below.

type Pair struct {
   Col1 string
   Col2 string
}
bindParams := [] Pair{...}

SQLテストランナー

コンテキストとスコープ

アプリケーションコードを書かずに、SQLだけで高速にテスト駆動開発を行い、品質の高いSQLを書く環境を用意する。

Markdownに書かれたテストケースを読み込んで、テストを実行する。

また、サブの機能としてtwowaysql.RunTestメソッドを提供し、ユニットテストに組み込めるようにする。

ゴール

• プロジェクトで使用するSQL類を一括でテストする
• テストケースはSQLを書いたMarkdownで記述する
  • テストケースには、テストデータ、パラメータ、結果を含む

ゴール外

• カバレッジ計測は将来的にはやりたいがコアへの変更が必要なのでこのDesign Docの対象外とする
• 実行時にシーケンシャルスキャンがあったらエラーにするなど

実際のデザイン

Markdownに書かれたテストケースの抽出を行い、実行をする。

Markdownはセクションタイトルのルールを定めて、テストケースの情報を記述する。

実行時はまずはトランザクションでくくって、テスト終了後にDBを戻せるようにする。事前に投入するデータがあればそれを入れる。その後対象のクエリーを実行し、テストケースに書かれた検証手法（レスポンス、あるいはDBの内容、外部のファイルなどのチェック）で検証する。最後にロールバックする

テストデータは以下の形式をサポート

• YAML
• SQL

パラメータと期待する結果はYAML形式をサポート

また、アプリケーションのテストコードに追加可能な関数も提供する。

sqltest.RunTest(t, db, "testdata/sqlr")

システムコンテキスト図

graph TD;

Markdown -->|読み込み| テストランナー
テストランナー --> テスト結果

コードと疑似コード

以下はMarkdownのサンプル。

# タイトル

```sql
SELECT email, name FROM users WHERE name=/*name*/'bob';
```

## Test

テストの事前データはYAMLでコンパクトに書いて各テーブルにinsertする想定。名前に(reset)がついていたら、一度テーブルの中をすべて空にしてからinsert。Testセクション以下は全テストの前で毎回実行されるもの（結果は毎回rollback)

```yaml
fixtures:
  - users
    - [employee_no, dept_no, first_name, last_name, email]
	- [1, 10, Evan, MacMans, [email protected]]
    - [2, 11, Malvin, FitzSimons, [email protected]]
    - [3, 12, Jimmie, Bruce, [email protected]]
```

あるいはSQLを書いても良い。これもtx.Execで実行される。

```sql
INSERT INTO persons(employee_no, dept_no, first_name, last_name, email, created_at) VALUES
			(1, 10, 'Evan', 'MacMans', '[email protected]', CURRENT_TIMESTAMP),
			(2, 11, 'Malvina', 'FitzSimons', '[email protected]', CURRENT_TIMESTAMP),
			(3, 12, 'Jimmie', 'Bruce', '[email protected]', CURRENT_TIMESTAMP)
			;
```

### Case: query test with alice

各テストケースではYAMLを書く

fixture/fixturesは全体のfixturesに追加して入れられる。
param/paramsは実行パラメータ
結果は以下のキーで記述する

- result: tx.Selectで実行。結果は順番通りの比較

```yaml
fixtures:
  - users
	- ["", "", ""]
params: { name: "Alice" }
result:
  - { email: [email protected], name: Alice }
```

### Case: exec test

deleteやupdate、insertの場合はその後の検証用クエリーをtestQueryに書く。

```yaml
fixtures:
  - users
	- ["", "", ""]
params: { name: "Alice" }
testQuery: "select count(id) as count  from users"
result:
  - { count: 1 }
```

制約の度合い

• GitHubなどのMarkdownで記述でき、複雑な記法とならない程度のMarkdownの書き方にする必要がある

Fix a bug that caused an error when using pointer types in struct parameters.