GORM 映射宣言 :: 太长或不太长

Question

相当基本的问题，但它的根源深深植根于框架中（并且关于该主题的明确信息很少），因此我将其放在这里，以减轻其他人的痛苦（并验证我的想法是否正确） ）。

问题是什么？

Grails 会自动将 Long 类型的 id 字段注入到您的域中 (请参阅 Beckwith 的评论）。当使用旧版数据库时，Grails 默认将 Long 映射到 bigint，这是一种低效的存储类型，任何处理超过百万条记录的表的人都会避免这种低效的存储类型。

几个月前发现这一点后，我开始努力为我的域 ID 找到一个“正确的”列类型。没有Java背景，我盲目地认为，Long-bad，Integer-good，并将整数类型的hibernate映射方言设置为我在mysql中手动执行的操作

registerColumnType(Types.INTEGER, 'mediumint unsigned')

然后在我的所有域中定义“Integer id”（根据上面链接中的 Bert 评论，这不是必需的）。一切都进展顺利、美妙，其他事情也是如此。

快进到 Grails 2.0（因为我无法抗拒所有的好处;-)）和 Spock。我一生都无法弄清楚为什么，尽管 2.0 新的内存 GORM 和对动态查找器的支持，Domain.findByFoo(fooVal) 总是返回 null（是的，我 @Mock(Domain) 并填充测试数据）。事实上，在测试本身和 @TestFor 目标中，唯一有效的 GORM 方法是 save() 和 get()；其他一切都返回 null。

我制作了一个快速测试应用程序，域 + 控制器 + spoc 规范，并发现了问题的根源：如果您使用 Long 以外的属性类型作为您的 id（包括引用的 FK），您的 @Mock 域将被渲染无用。

那么，我说必须使用长 ID 才能充分利用该框架是否正确？ @Mock + @TestFor + Spock 是一个令人难以置信的组合！在我踏上重构之路之前，感谢您的指导......

Answer 1

我无法想象任何现实的场景，其中 Integer 和 Long 之间的差异会对性能产生任何明显的差异（这似乎是进行此更改的原始动机）。

如果使用 Long 有效，但 Integer 会导致问题，则使用 Long 并转向更重要的任务。只有当您能够证明使用 Integer 会产生显着差异时，我才会担心这一点。

更新

你是对的，我确实完全忽略了 Grails 自动使用 Long 的数据库类型的要点。正如您似乎已经知道的那样，您可以在域类的映射闭包中控制数据库类型，例如

class Person {
   Long id

   static mapping = {
      // See here for alternatives to integer, and how they map to DB types
      // http://docs.jboss.org/hibernate/stable/core/manual/en-US/html/mapping.html#mapping-types-basictypes
      id type:'integer'
   }
}

您还在评论中提出

在代码级别处理 Long，必须指定 def foo(Long id) {...} 和 params.id.toLong() 而不是 Integer

您可以简单地将操作定义为

def myAction = {Person p ->

}

or

def myAction = {
   Person p = new Person(params)
}

并且 Grails 将负责类型转换Person.id 的 id 请求参数，无论它是 Long、Integer、BigDecimal 等。