Home > OS >  org.jooq.lambda.tuple - Create Tuples
org.jooq.lambda.tuple - Create Tuples

Time:05-27

In my project, I need to use org.jooq.lambda.Tuple for mapping fields for simpleflatmapper JdbcMapperFactory:

public static final JdbcMapper<Tuple17<
        Entity1,
        Entity2,
        Entity3,
        Entity4,
        Entity5,
        Entity6,
        Entity7,
        Entity8,
        Entity9,
        Entity10,
        Entity11,
        Entity12,
        Entity13,
        Entity14,
        Entity15,
        Entity16,
        Entity17
        >> MAPPER =
        JdbcMapperFactory
                .newInstance()
                .unorderedJoin()
                .newMapper(
                        new TypeReference<>() {
                        });

But I have only 16 tuples in package org.jooq.lambda.tuple of library org.jooq.jool:0.9.12

My Idea is to avoid writing boilerplate code for my next Tuple17,18,19... etc.

In addition, I have been looking for a long time for a mention of similar, ready-made structures for Jooq, but I could not find it. Also, I can't find any generators of such Tuples.

Can somebody help?

CodePudding user response:

If languages cannot abstract over "generic type variable arity," libraries have to work around this by creating types like jOOλ's Tuple[N] types (max(N) = 16) or jOOQ's Record[N] types (max(N) = 22). The upper bound of type safety is arbitrarily chosen. There's no good reason for one or the other number. So, you will inevitably run into the limitation you ran into, eventually.

There are usually tools to nest tuples in order to work around this. I.e. there's no significant difference between the two types below:

Tuple3<A, B, C>
Tuple2<A, Tuple2<B, C>>

If you must use the stack you've started using (jOOλ and SimpleFlatMapper), then I suspect that this is one way to work around the limitation you've encountered. Surely, there are other ways, e.g.

  • At some point, you can just use an Object[] and waive type safety.
  • If you're using jOOQ, you could use nested records already inside of jOOQ / SQL, so you never realistically reach this limit of 16 attributes

The latter suggestion hints at there possibly being a jOOQ-only solution to your underlying problem, which removes the need for the other two libraries. I'm happy to look into that option in a follow-up question.

  • Related