Golang Go语言中GORM v2 正式发布 20k stars
Golang Go语言中GORM v2 正式发布 20k stars
GORM 2.0 从零开始重写，根据过去几年的用户反馈吐槽，做了大量的改进，历经半年终于达成 ;)
主要更新
- 性能改进
- 代码模块化
- Context，批量插入，预编译模式，DryRun 模式，Join 预加载，Find To Map，Create From Map，FindInBatches
- 支持嵌套事务，SavePoint，Rollback To SavePoint
- SQL 生成器，命名参数，分组条件，Upsert，锁， 支持 Optimizer/Index/Comment Hint，子查询改进，使用 SQL 表达式、Context Valuer 进行 CRUD
- 支持完整的自引用，改进 Join Table，批量数据的关联模式
- 允许多个字段用于追踪 create 、update 时间 ，支持 UNIX （毫 /纳）秒
- 支持字段权限：只读、只写、只创建、只更新、忽略
- 新的插件系统，为多个数据库提供了官方插件，读写分离，prometheus 集成...
- 全新的 Hook API：带插件的统一接口
- 全新的 Migrator：允许为关系创建数据库外键，更智能的 AutoMigrate，支持约束、检查器，增强索引支持
- 全新的 Logger：支持 context 、改进可扩展性
- 统一命名策略：表名、字段名、连接表名、外键、检查器、索引名称规则
- 更好的自定义类型支持（例如：JSON ）
详情请参考 Release Note
更多关于Golang Go语言中GORM v2 正式发布 20k stars的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
诸位大佬，小弟有一问求教，查询记录不存在时，大佬们都是在哪一层处理它呀？
小弟现在是在业务层使用 gorm.isRecordNotFound()对 gorm 查询返回的错误判断一记，之前也尝试过在查询方法中返回(*data, *error)，将记录未找到的错误场景处理为返回(nil, nil)。两种都感觉怪怪的。
我对 gorm 最大的体验是，作者应该有很强的函数化编程背景，所以很重度使用函数化，各种 hook
而我对于中间件类型代码，是很反对函数化
我对中间件类型代码的要求，就是 Go 本身源代码，我一眼看下去就知道在做什么
我一般的是在 model 层处理
我一般的做法是：例如用 UID 查询，当记录不存在的时候返回 nil，同时 user.UID = 0，上一次判断 user.UID 是否等于 0 来判断记录存不存在
不过感觉好像也不是很好
函数化为了提供一些扩展可能性，在一些场景下还是挺需要的，不过排斥这个的话也没有关系，甚至可以用 GORM 的 raw sql 模式，他对 named argument 之类的支持应该也比其它的 sql builder 好一些，并且也不重
请问一下，就是 gorm 里面的 offset 和 limit 它们要求传入的是 int 型。可是表行数有可能会超过 int 的范围，按理说应该得接受传入 int64 比较合理。请问这边这样设计是有啥原因吗？
是我在各个语言里遇到的最难用的 orm 。
而且因为 start 太多 导致其他人不愿意去写一个类似的库。毕竟这个东西更大消耗是在维护上。
我怀疑作者根本没看过其他 orm 的实现，或者一开始没有投入什么精力，一厢情愿的提供了零碎的东西，写着玩玩，可以称之为玩具。敢用在生产环境也的人也是疯了。
只针对 gorm1，gorm2 还没看。
Go 的 ORM 还真不少
> 我怀疑作者根本没看过其他 orm 的实现，或者一开始没有投入什么精力，一厢情愿的提供了零碎的东西，写着玩玩，可以称之为玩具。敢用在生产环境也的人也是疯了。
现在可以直接喷，不列证据了么？
大佬我插个题外话。
你现在都转用 Jetbrains 的产品呢了么。这几年 Emacs 和 Vim dot file 都没怎么更新。以前看到你说从 Vim 转 Emacs 了，现在是不是又回去 Vim 了。纯属好奇。😂
现在 tmux + vim 用的挺爽的。。。之前 emacs 试了一段时间，可能单进程的原因导致经常卡，就回到 vim 了，现在个人配置文件放私有仓库了… 所以没更新。。。
最新版本啥时候发布呢？遇到了这个问题。看到是已经解决了。但是没发
Gorm writes wrong SQL when trying to alter existing column for PostgreSQL
https://github.com/go-gorm/gorm/issues/3339
请问查询单个字段怎么 scan 到变量而不是结构体，文档的例子 scan 到 int 类型的变量可以，但是数据库查询 varchar 的字段 scan 到 steing 类型的变量不行。
现在 Gorm 是不是不需要手动关闭连接了。
V1 有 db.Close()，V2 好像得 db.DB() 拿到 sql.DB 之后进行关闭。
关闭这个步骤在 V2 里面不再是必须的了？
最新版本应该可以了
其实对于大多数应用 v1 版本也不需要 Close，用连接池就好了，好多人用错，于是直接把 Close 方法去掉了，刚需 Close 的人应该也能从文档里找到怎么用
问题一：v2 版本添加索引值只能在对象的 tag 添加吗，手动进行迁移时不能和 v1 一样单独添加吗，这样添加多个索引时对象 tag 会很长，而且 gorm.Model 软删除的字段也添加不进联合索引
问题二：自动迁移时添加外键关联会把外键的相关结构体的外键字段数据库生成时会自动生成为 bigint 类型，而不是我关联结构体定义的类型，这个怎么破？
针对Golang中GORM v2正式发布的帖子，作为IT营GO语言方面的专家，以下是我的回复：
GORM v2的正式发布无疑是Golang社区的一大喜讯，其收获20k stars也充分证明了其在ORM（对象关系映射）领域的卓越表现和广泛认可。
GORM v2从零开始重写，根据用户反馈进行了大量改进。其性能得到了显著提升，并引入了诸多新功能，如代码模块化、批量插入、预编译模式、DryRun模式、Join预加载等。此外，GORM v2还支持嵌套事务、SavePoint、Rollback To SavePoint等高级数据库操作，为开发者提供了更加灵活和强大的数据库操作能力。
在数据写操作方面，GORM v2也提供了丰富的API，支持普通创建、选定字段创建、排除字段创建、批量创建等多种操作方式。同时，它还支持根据map创建记录，为开发者提供了更加便捷的数据插入方式。
总的来说，GORM v2的发布为Golang开发者提供了更加强大、灵活和易用的ORM库。相信在未来的日子里，GORM将继续保持其领先地位，为Golang社区的发展做出更大的贡献。
