The thing I like more with ORMs is that they are class-first. One creates the entity, annotates it correctly and generate the schema.
For those liking a schema-first approach, I like a lot the Querydsl project. 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).
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:
// Q* are the generated classes for the Querydsl metamodel
QPerson p = QPerson.person;
List<Person> admins = query
p.isActive()) // This would be a custom method via extension
Em terça-feira, 9 de março de 2021 às 12:10:44 UTC-3, aka...@gmail.com escreveu:
I don't like Hibernate/JPA because of the horror and terror it gave me during my career years. YetHibernate appeared in times when we were having a hard time dealing with database and SQL in java, mapping/parsing query results, or even constructing the queries themselves and I have seen it going wildly bad.Hibernate then came with its benefits and problems .. (maybe too many problems) but it came first .. and was adopted by so many.. and it became a large part of Java ecosystem ..so large that you hardly find a project that talks to the database and not using hibernate.. (we would like to see more of this)I am not sure but maybe hibernate was there around 2008 (the oldest version I checked in maven central) imagine by that we had JOOQ first ..or JDBI ..or whatever suggested alternative... (I think most of them came after 2010 checking the issue trackers on Github) .. imagine we had text blocks :-) way before hibernate came along.Now you see projects using hibernate for no reason (especially with how easy it is being promoted by spring).. from using it for simple CRUD (can be replaced by one of the suggested solutions) or for the complex queries (which should be replaced with one of the suggested solutions) I think.BTW,@Thomas you didn't start a flame war it was just a flame, I got to learn few things from this conversation so why not flame the rest of the list?On Tuesday, March 9, 2021 at 3:44:02 PM UTC+2 t.br...@gmail.com wrote:Main issues with JPA: the entity caches, and lazy-loading which makes things work but are a PITA for performance (I've worked on a project where each and every HTTP request causes between 10 and 30 SQL queries, only to get the user's information and access rights; being so bad might very well be caused by the app architecture too, as it also has N+1 issues on some screens; but definitely JPA is to blame as well).(also, the Criteria API is 🤢)On Tuesday, March 9, 2021 at 10:34:18 AM UTC+1 lofid...@gmail.com wrote:@TBroyer: of course we are going to start a flame war for Hibernate ;-)"Hibernate" is the most searched word in Google 2021... OK, I mean "how to hibernate your PC" :-)I agree with @Gordan, it depends on the use case. Strangely enough, we have today ORM also on Android Room (https://developer.android.com/training/data-storage/room) and iOS Core Data (https://developer.apple.com/documentation/coredata). So from the resources and speed point of view, it seems that they are just fine.Actually it's a pitty that the standard SQLJ (https://en.wikipedia.org/wiki/SQLJ) did not get any further, I think it would be a good choice if you need SQL but need the "type and compile time" safety in Java.Cheers,LofiGordan Krešić schrieb am Dienstag, 9. März 2021 um 09:11:06 UTC+1:On 09. 03. 2021. 08:29, Craig Mitchell wrote:
> Too late. Flame war! ;P But seriously, what's wrong with using Hibernate
> as JPA provider? Okay, yes, there is nothing to learn, it does all its
> magic behind the scenes, but is there something better? Or maybe using JPA
> is bad, and we go back to pure SQL? I'm curious.
I did try various ORMs, including some for non-relational databases (but
then it's not an ORM, but... what?) but never figured out the benefits. They
all demo well, but when I go past most basic usage, they always felt more
like an obstacle than a tool.
Only case where I would agree using ORM saves time are projects with high
number of tables compared to complexity of their usage (simple SELECTs on
hundreds or thousands of tables). But, I don't have such a project in my
Can you name few other benefits? Type safety? "Compile-time checks" of SQL
"queries"? I can see *some* benefits there, but hardly ones that justifies
learning another, fairly complex, DSL on top of SQL.
From time to time I found a survey with question like "Which ORM do you
use?" and there are usually low-double-digits of percentages of users who
claim to be using "raw JDBC with SQL". It gives me hope that I'm not a lone
lunatic, but still, 80+% of users must know *something*, right?
So, if we assume that someone already knows SQL (and it's an 'if', I know),
what would be the benefits of using ORM of any kind?
Bonus question: I've been looking for years for a most simplistic SQL
templating library, mainly for things like reusing WHERE clauses (i usually
end up with fairly complex ones used in multiple queries), linking '?' with
setters on PreparedStatements and things like that. I even wrote small lib
because I was tired of experimenting, but I seriously doubt that I'm the
only one with this need and would instead like to contribute to already
existing project rather than maintain my own.
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 firstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/45f8410e-8301-4de5-ad98-aa80a6c5ddc9n%40googlegroups.com.
Post a Comment