Panache: Incorporate features from EBean ORM for Panache or join development effort?

[tmulle]

Description

One of the legacy projects I'm working on converting from a Play/Scala/EBean ORM application to run on Quarkus uses EBean ORM instead of JPA/Hibernate. It was written 10+ years ago.

I want to be 100% quarkus eco-system so I can work with the DEV mode.

And unfortunately, EBean doesn't work with quarkus DEV mode, and the developer is only one person.

During the conversion of the data layer I find EBean has a lot of nice syntax for building queries that Panache I think could benefit from if you want to make it a "simplified" Hibernate alternative.

I'm not affiliated with EBean in anyway, just was introduced through my current conversion.

I think it might be worth while for the developers of Panache to reach out to the creator of EBean (if you haven't already) and maybe work together to join forces on JPA persistence.

The author claims he does a lot of things "correctly" that Hibernate gets wrong, and he does other "optimizations", etc.

I can't validate those, I just really like the syntax of building queries. I find myself having to manually rewrite the old legacy code into raw JPA/HQL when I have to search on more than one field/criteria in Panache.

For example, here is how I have to rewrite queries, not terrible for this example, but gets pretty involved when the criteria because larger with more fields and things like iLike, ne, gt, etc.

// EBean
List<CrumbModel> allModels = CrumbModel.find.query().where().ne("modelName", "ALL").order().asc("modelName").findList();

// Panache
List<CrumbModel> allModels = CrumbModel.list("modelName != :name", Sort.ascending("modelName"), Parameters.with("name", "ALL"));

Here is another example of doing FETCHES in EBean:

if (currUser.isPrivleged()) {
            expOrg = OrgUser.find.query().fetch("user").where().like("user.email", term);
        } else {
            expOrg = OrgUser.find.query().fetch("user").where().eq("org.orgId", currUser.getOrg().getOrgId()).like("user.email", term);
        }

Just a thought...

https://ebean.io

Implementation ideas

No response

[quarkus-bot]

/cc @FroMage (panache), @loicmathieu (panache)

[melloware]

@tmulle have you checked out JPA streamer instead of Panache? It looks more like EBean.

See: https://github.com/quarkiverse/quarkus-jpastreamer

[rbygrave]

JPA streamer

Ebean query beans are similar to JPA streamer - https://ebean.io/docs/query/query-beans ... for writing queries in a more type safe manor.

With Ebean query beans (type safe) you'd write that first query as:

List<CrumbModel> allModels = 
  new QCrumbModel()
    .modelName.ne("ALL")
    .orderBy().modelName.asc()
    .findList();

... QCrumbModel as a "query bean" that is generated via an annotation processor.

[blaluc]

@rbygrave do you have any clue about how to make ebean working in quarkus dev mode (with hot-reload). From what I see, as soon as you modify an entity class, the reload phase fails with the message:

error: Failed to initialise EntityClassRegister error:javax.annotation.processing.FilerException: Attempt to recreate a file for type
 EbeanEntityRegister stack:[jdk.compiler/com.sun.tools.javac.processing.JavacFiler.checkNameAndExistence(JavacFiler.java:741),
 jdk.compiler/com.sun.tools.javac.processing.JavacFiler.createSourceOrClassFile(JavacFiler.java:498), 
jdk.compiler/com.sun.tools.javac.processing.JavacFiler.createSourceFile(JavacFiler.java:435), 
io.ebean.querybean.generator.ProcessingContext.createWriter(ProcessingContext.java:399), 
...
error: EntityClassRegister was not initialised and not written
	at io.quarkus.deployment.dev.JavaCompilationProvider.compile(JavaCompilationProvider.java:114)
	at io.quarkus.deployment.dev.QuarkusCompiler.compile(QuarkusCompiler.java:232)

[FroMage]

Have you tried the JPA Criteria API?

https://jakarta.ee/learn/docs/jakartaee-tutorial/current/persist/persistence-criteria/persistence-criteria.html

We could add support in Panache to make using this easier.

[rbygrave]

@rbygrave do you have any clue about ... error: Failed to initialise EntityClassRegister ...

This is an error that the ebean querybean-generator annotation processor reports. It looks like the querybean-generator is looking to get the FileWriter such that it can later on write the generated for for EntityClassRegister.

What this generated EntityClassRegister does, is it knows all of the entity bean classes (plus other bits like AttributeConverters etc) and allows Ebean to start up faster by registering those as known rather than scanning the classpath for them etc. Thats interesting because if we are just modifying an existing entity bean in this hot-reload mode, then that would be fine for EntityClassRegister per se.

(with hot-reload) ... as soon as you modify an entity class, the reload phase fails

Pretty confident that the EntityClassRegister already exists / it was already generated in some prior compilation. So now in some hot-reload / perform some incremental compilation mode, the querybean-generator is again trying to obtain that FileWriter and that fails because it already exists.

any clue about how to make ebean working in quarkus dev mode (with hot-reload).

There are definitely a few things that could be tried.

1. My gut says that if querybean-generator treated this as a WARNING and not an ERROR then, yes it would give us the ugly warning message but it would still actually work. Once an annotation processor logs an ERROR than that means the compilation will fail/stop but warnings still allow the compilation to continue etc.
2. Find out if querybean-generator can detect that its executing in quarkus dev mode. Perhaps there is a system property or something to indicate that.
3. Something odd and unique in querybean-generator? It doesn't look like it yet.

[rbygrave]

wrt ebean querybean-generator error: Failed to initialise EntityClassRegister ... ... I have logged that as ebean-orm/ebean#3541

I have released an RC version if you want to try it - io.ebean:querybean-generator:14.8.2-RC1

Note that there are some other issues I see in that the hot reload compilation does not apply the ebean enhancement so we can't perform changes to query bean queries in this mode per se.