Kotilin fInder generation

[ivaneyvieira]

I found a problem in generating the class finder. The keys "{" and "}" of the class are missing. So I'm following this little code change.

[rbygrave]

Did you read the issue https://github.com/ebean-orm-tools/finder-generator/issues/26

It still is not clear to me what the problem is given that we technically don't need { } for kotlin to compile the finder that is generated.

Can you clarify what the problem is? Thanks.

[ivaneyvieira]

Yes I agree, kotlin doesn't need {} to compile. But it also generates a where method that should belong to class Finder. Example:

...
open class AbreviacaoFinder: Finder<Long, Abreviacao>(Abreviacao::class.java) 
  /**
   * Start a new typed query.
   */
  fun where(): QAbreviacao {
    return QAbreviacao(db())
  }
...

The problem happens when there are more than one class Finder in the same package. Without {}, the where method does not belong to the Finder class and in this case there is an "Overload Conflict" because there is a where method defined in more than one file.

With {} there are no compilation errors:

...
open class AbreviacaoFinder: Finder<Long, Abreviacao>(Abreviacao::class.java) {
  /**
   * Start a new typed query.
   */
  fun where(): QAbreviacao {
    return QAbreviacao(db())
  }
}
...

[rbygrave]

> But it also generates a where method

Ah. That is the difference I believe then.

I don't think it should generate that where() function. I'm using the latest ebeaninit tool that uses FinderGenerator under the hood and it doesn't. I'll have to investigate but no we should not really be generating that where() function anymore.

I wonder if you are using FinderGenerator directly or via ebeaninit or some other way?

Cheers, Rob.

On Wed, 27 Nov 2019 at 16:46, Ivaney Vieira de Sales < notifications@github.com> wrote:

Yes I agree, kotlin doesn't need {} to compile. But it also generates a where method that should belong to class Finder. Example:

... open class AbreviacaoFinder: Finder<Long, Abreviacao>(Abreviacao::class.java) /**

• Start a new typed query. */ fun where(): QAbreviacao { return QAbreviacao(db()) } ...

The problem happens when there are more than one class Finder in the same package. Without {}, the where method does not belong to the Finder class and in this case there is an "Overload Conflict" because there is a where method defined in more than one file.

With {} there are no compilation errors:

... open class AbreviacaoFinder: Finder<Long, Abreviacao>(Abreviacao::class.java) { /**

• Start a new typed query. */ fun where(): QAbreviacao { return QAbreviacao(db()) } } ...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ebean-orm-tools/finder-generator/pull/30?email_source=notifications&email_token=AABTATI2K7ONGB72GP2D5N3QVXUS7A5CNFSM4JR5ETW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFIGCHI#issuecomment-558915869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTATKYVRRU7KPNBOIHGFDQVXUS7ANCNFSM4JR5ETWQ .

[ivaneyvieira]

I am using the following code to generate:

fun main() {
  val config = GeneratorConfig()
  config.lang = LANG_KOTLIN
  config.classesDirectory = "./out/production/classes/"
  config.destDirectory = "./src/main/kotlin"
  config.destResourceDirectory = "./src/main/resources"

  config.entityBeanPackage = "br.com.engecopi.estoque.model"
  config.destPackage = "br.com.engecopi.estoque.model.query"

  config.isAddFinderTextMethod = false
  config.isAddFinderWherePublic = false

  config.isOverwriteExistingFinders = true
  val generator = GeneratorKotlin(config)
  generator.generateQueryBeans()
  // Additionally generate 'finder's
  generator.generateFinders()
  generator.modifyEntityBeansAddFinderField()
}

[rbygrave]

Cool.

I think the fix for this issue is to remove the generation of the where() function altogether (as I don't believe we want it anymore).

Note I expect most people to use the FinderGenerator via the ebeaninit cli tool. https://ebean.io/docs/getting-started/cli-tool

[rbygrave]

Adjusted the change to only include { and } when we generate the where() or text() functions.

Note that in general we don't want to generate those methods such that we can better use "profile location enhancement" ... which labels / identifies queries using code location (the line of code that executes the query).

So with that we also turn off the generation of where() etc by default.