直接 ToLower 表名有大写怎么办啊😲

[iseki0]

sqlw/convert.go

Lines 576 to 583 in 7be0054

	func updateContext(ctx context.Context, selector Selector, db *DB, stmt *Stmt, sqlHead string, data interface{}, args ...interface{}) (Result, error) {
	isStmt := (stmt != nil)
	if !isStmt && sqlHead == "" {
	return nil, fmt.Errorf("[sqlw %v] invalid sql head: %v", opTypInsert, sqlHead)
	}
	sqlHead = strings.ToLower(sqlHead)
	// if strings.Contains(sqlHead, opTypSelect) ||

[lesismal]

啊确实，我自己习惯了全小写。这块应该改下，取set那些操作字段的时候用临时的tolower，实际拼接的时候用用户传入的，也包括字段那些、都去掉ToLower，有兴趣来个pr没 😄

[iseki0]

晚点我看看，应该好弄，你那个 parse 函数不复杂

[iseki0]

还有个事，我不知道你有没有这种需求，一个典型需求需要用 insert ... values ... on conflict do update set .... ，set 后面非常长，我有时离不开 gorm 的一个关键就是，不想自己写这个😰

[lesismal]

还有个事，我不知道你有没有这种需求，一个典型需求需要用 insert ... values ... on conflict do update set .... ，set 后面非常长，我有时离不开 gorm 的一个关键就是，不想自己写这个😰

我看下现在的能不能简单搞这个。
如果不行的话，各个数据库自己特有的不太好做成通用的，那就考虑做个通用的binding、用户Exec后面传入的参数里解析下binding相关的

[iseki0]

我觉得如果要进一步做得很完善，这个工作量还是比较恐怖的

[lesismal]

我觉得如果要进一步做得很完善，这个工作量还是比较恐怖的

是啊，现在都是最小功能集合加上我自己的使用习惯、特殊的得用户自己用标准库Exec这些。

[lesismal]

还有个事，我不知道你有没有这种需求，一个典型需求需要用 insert ... values ... on conflict do update set .... ，set 后面非常长，我有时离不开 gorm 的一个关键就是，不想自己写这个😰

想了下，通用的不太好搞，比如update的时候不是设置到结构体字段、而是一些字段设置结构体、一些字段设置为以前字段增量比如a=a+1。要做通用，只能按 field=占位符 这种，根据占位符个数和 field name 去参数列表的结构体里解析对应的相同tag的结构体字段，结构体字段没有了再取普通参数类型，虽然麻烦但是可以搞但是不优雅、使用也比较乱，可能还不如用户自己Exec语句。。

[iseki0]

还有个事，我不知道你有没有这种需求，一个典型需求需要用 insert ... values ... on conflict do update set .... ，set 后面非常长，我有时离不开 gorm 的一个关键就是，不想自己写这个😰

想了下，通用的不太好搞，比如update的时候不是设置到结构体字段、而是一些字段设置结构体、一些字段设置为以前字段增量比如a=a+1。要做通用，只能按 field=占位符 这种，根据占位符个数和 field name 去参数列表的结构体里解析对应的相同tag的结构体字段，结构体字段没有了再取普通参数类型，虽然麻烦但是可以搞但是不优雅、使用也比较乱，可能还不如用户自己Exec语句。。

实际上关于这个需求，新的 SQL 标准提供了 MERGE 命令，PostgreSQL 从 15 开始支持，它比带有 ON CONFLICT DO UPDATE 子句的 INSERT 命令要更强大

[lesismal]

我觉得如果要进一步做得很完善，这个工作量还是比较恐怖的

现在sqlw提供的 Select/Insert/Update/Delete 主要是 mapping && binding 的便利、应该能覆盖到多数业务逻辑了。
标准库也只有 Query 和 Exec，而且最麻烦的是 Query 结果的 binding ，Exec 相关的也就是 sql语句和参数列表太长的时候。如果抛开 Query、需要Exec的少量地方直接标准库也还好，但 ON CONFLICT DO UPDATE 确实算是个特例

现在的 Insert 是支持用户的 sqlHead 不用输入 values() 自动结构体按照前面的字段做对应的 values 填充：

但 ON CONFLICT DO UPDATE 用户自己是否带 values、并且 values 在语句里处于中间，这个还是有点麻烦，暂时还是没想好怎么弄，弄成链式的传两次参数分别做绑定倒是可以相对优雅点处理这种复杂入参，但是与已有的其他方法的风格不太符合了

[lesismal]

昨天改了点，保留用户原始的sql语句部分，在这个分支：
https://github.com/lesismal/sqlw/tree/fix_lower_case

[iseki0]

😪这两天事情有点多，我可能会做如下改动：

1. 数据库配置要增加一个 Quote 字符配置，MySQL 使用 ` PostgreSQL 使用 "
2. 自动补充的标识符，需要 quote 起来，包括 "field" 和 "schema"."field" 一来大小写敏感时必须这么写，二来避免关键字问题，比如说你现在这个拼法我没测试，我不确定它会不会在 PostgreSQL 使用一个叫 user 的数据表或者 order 的字段时出问题。

[iseki0]

我不确定它会不会在 PostgreSQL 使用一个叫 user 的数据表或者 order 的字段时出问题。

PostgreSQL 规定在这种情况下必须 quote，否则 parser 会把这个东西当作关键字然后报错

[iseki0]

很多 ORM 使用 dialect 机制，把这种 Quote 工作转移到 dialect 内部处理，避免在 ORM 本体枚举不同数据库的不同处理方式以保证通用性和扩展性。
比如说国产数据库达梦，如果需要在 INSERT 语句中返回上次插入 ID，需要在 INSERT 命令前包裹一组 SET 命令搬开关，gorm 在这里就出了个小问题，它打日志是写死的打最后一条命令的日志，于是所有 INSERT 命令，打的日志都是关开关的 SET 命令···毫无意义

[lesismal]

1. 数据库配置要增加一个 Quote 字符配置，MySQL 使用 ` PostgreSQL 使用 "
2. 自动补充的标识符，需要 quote 起来，包括 "field" 和 "schema"."field" 一来大小写敏感时必须这么写，二来避免关键字问题，比如说你现在这个拼法我没测试，我不确定它会不会在 PostgreSQL 使用一个叫 user 的数据表或者 order 的字段时出问题。

加 quote 可以，加个string或者func配置项处理
现在的可以通过 result.Sql() 打印出语句查看实际的拼接

[lesismal]

比如说国产数据库达梦，如果需要在 INSERT 语句中返回上次插入 ID，需要在 INSERT 命令前包裹一组 SET 命令搬开关，gorm 在这里就出了个小问题，它打日志是写死的打最后一条命令的日志，于是所有 INSERT 命令，打的日志都是关开关的 SET 命令···毫无意义

这个确实不好搞了，用户输入的语句可能非常复杂