The problem about Kotlin OutputDTO and Jacoco

[babyfish-ct]

A long time ago, jimmer was asked to integrate jacoco, #543

After this feature is completed, for kotlin, the generated Output DTO does not use the Kotlin Fetcher DSL, but uses the low-level original API, like this

open class BookView(...ommit...) {
    @GeneratedBy
    public companion object {
        @JvmStatic
        public val METADATA: DtoMetadata<Book, BookView> = 
            DtoMetadata<Book, BookView>(
                // Use low level API to create fetcher 
                // to avoid anonymous lambda that affects 
                // coverage of non-kotlin-friendly tools
                // such as jacoco
                FetcherImpl(Book::class.java)
                    .add("name")
                    .add("edition")
                    .add("store", TargetOf_store.METADATA.fetcher)
                    .add("authors", TargetOf_authors.METADATA.fetcher),
                ::BookView
            )
    }
}

Now, I have completed the enhancement of the DTO language to support property-level filters (code is committed into dev branch), next, the SQL conditions must be generated in the Kotlin Output DTO.

However, as you can see, the generated kotlin OutputDTO does not use the Kotlin Fetcher DSL (of course, it is even less likely to be the Java Fetcher DSL), but a low-level API. Building SQL expressions based on the low-level API is a headache.

Two options

1. Continue to support jacoco, craate an auxiliary class to encapsulate all unsafe operations to provide a Predicate DSL that is only used by the Kotlin Output Fetcher. Of course, the generated code is very obscure.

2. Give up supporting jacoco and use Kotlin Fetcher DSL in Kotlin Output DTO to generate a Predicate that is exactly the same as the one written by the user. The generated code is easy to read.

I carefully viewed that FR again, generated code can be excluded by jacoco. So I think I can select 2 and refactor the Fetcher in kotlin output DTO to support property level predicate, is it right?

[ArgonarioD]

2

1. Kotlin projects have dedicated code coverage tools (e.g. Kover)

2. For such issues, an appropriate allowlist strategy can be employed

[babyfish-ct]

I generated property level filter and got compilation errors. Oh, that is lower level API, not kotlin fetcher DSL.