On Thursday, March 11, 2021 at 3:39:37 PM UTC+1 Luis Fernando Planella Gonzalez wrote:
> We use JPA with EclipseLink. Gave us a lot better performance than > Hibernate when we compared both. > The thing I like more with ORMs is that they are class-first. One creates > the entity, annotates it correctly and generate the schema. > Ah yes, that's also one of those things I dislike about JPA 😊 And retrofitting JPA on an existing schema is… not easy (or leads to non-idiomatic entities). Fortunately I've only had to do that twice I think. Many performance issues I've seen had to do with databases when doing complex queries, so in addition to not fully controlling your SQL queries, you also don't fully control the schema; or maybe more accurately you have to learn how each JPA mapping strategy translates to SQL. Unless I'm mistaken, this also leads to putting zero or very few "check constraints" in the database (i.e. besides not null, unique constraints and referential integrity). Lately I've used exclusion constraints in Postgres (https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-EXCLUSION) to handle complex uniqueness or non-overlapping date ranges, and other check constraints for some things others would likely implement as "business rules" in the application (things like "if that enum field's value is A then this other field must be null, and otherwise then it must be non-null and positive", or simpler things like "only one of those 2 fields can be null at a time", and in some cases they must not both be null). > For those liking a schema-first approach, I like a lot the Querydsl > project <http://www.querydsl.com/>. It is not as active nowadays as it > used to be, but is very nice. > And works both for plain SQL and JPA (I HATE with passion the JPA criteria > queries, Querydsl is so much more readable). > Querydsl is quite similar to jOOQ (which can generate code from JPA entities too: https://www.jooq.org/doc/3.14/manual/code-generation/codegen-jpa/), although less "integrated" with JPA: https://www.jooq.org/doc/3.14/manual/sql-execution/alternative-execution-models/using-jooq-with-jpa/ jOOQ will always do native SQL though, whereas Querydsl will use JPQL (or similar). > It gives us typed queries and is very extensible. You can even define your > own extensions as annotated static methods and it generates those as > methods in the metamodel, so things like these are possible: > This is interesting. I've used extension methods in a Kotlin project, that alleviates the need for such a feature; but with Java indeed one would have to write isActive(p) without that. I'm actually not sure what I prefer. (fwiw, JPA Criteria with JPA Metamodel in JPA 2.0 also gives you typed queries; the API still is 🤢) > > // Q* are the generated classes for the Querydsl metamodel > QPerson p = QPerson.person; > List<Person> admins = query > .select(p) > .from(p) > .where( > p.role.eq(Role.ADMIN), > p.isActive()) // This would be a custom method via extension > .orderBy(p.name.asc()) > .fetch(); > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/77504c44-e66e-4df9-a1d7-b31bd1822b76n%40googlegroups.com.
