java - jOOQ 字段<T> = DSL.any(DSL.val(T...))

Question

这个问题是 ANY operator with jOOQ 的衍生问题和 Are arrays optimized in jOOQ & PostgreSQL? .

我有一个Field<T> field和List<T> values我想表达SQL identifier = any({... the values ...}) 。我尝试这样做:

field.equal(DSL.any(DSL.val(values.stream().toArray())))

(请注意，这是通用实现的一部分，因此我目前没有实际类型。我只有 Field<T> 和 List<T> 。)

但这不起作用，因为 API 接受 T...而不是Object...和field.equal(DSL.any(...))需要T 。所以，我将其更改为:

field.equal(DSL.any(DSL.val((T[]) values.stream().toArray())))

但是，评论中说我不应该这样做。可能是一个愚蠢的问题和Java而不是jOOQ问题，但应该如何完成？

附带问题:简单地接受 List<T> 不是一个好主意吗？在 API 中？这也可能会提高性能，因为我们避免了手动创建数组。

注意:field.equal(DSL.any(values.stream().toArray())) 的情况相同。和field.equal(DSL.any(DSL.array(values.stream().toArray()))) .

Answer 1

每次您使用带有不安全强制转换的 jOOQ API 时，您都应该想:我使用它是否正确？

就您而言，错误在这里:

DSL.val((T[]) values.stream().toArray())

构造此数组的正确方法是(假设 T 是 Integer ，此处):

DSL.val(values.stream().toArray(Integer[]::new))

或者，如果 values是 Collection ，那么更简单:

DSL.val(values.toArray(new Integer[0]))

将正确类型的数组传递给 jOOQ 非常重要，因为 jOOQ 将使用该数组的反射来确定它是什么数据类型，然后将其映射到例如PostgreSQL ?::int[]

Side question: isn't it a good idea to simply accept a List<T> in the API? This might also improve performance, since we are avoiding the manual array creation.

问题是Java删除了T的泛型类型信息，jOOQ 需要在各种边缘情况下正确转换绑定(bind)变量。所以，T[]是比 List<T> 更可取的类型在这种情况下。