Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Hibernate Tips: Usage  RSS feed

 
Divya Shiv
Ranch Hand
Posts: 93
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

What are the specific scenarios for which we would not prefer Hibernate ORM  to be implemented in the  applications.
 
Thorben Janssen
Author & Course Creator
Ranch Hand
Posts: 92
5
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hibernate works great for most insert, update and delete statements and for all select statements that are not too complex.
If most of your database requests require complex select statements, e.g. reporting use cases, you shouldn't use Hibernate.
 
Divya Shiv
Ranch Hand
Posts: 93
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you.
 
Jeane Lindford
Greenhorn
Posts: 17
Flex Java Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what you think of OpenSessionInView? it seems kind of deprecated to me

also, do you ever used auto commit (auto flush) in hibernate?
in which situation should I use it?

I see many users that dont trust hibernate to commit only when necessary

thank you
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure what "complex select statements" means, but I would make a few observations:

Back before JPA, when there were several competing ORM frameworks (Hibernate, JDO, and EJB), the people at Kodo JDO (now part of Oracle) observed that it was easier to get a Java expert than to get a Java/SQL expert. By having a java-like query language, you could hire less expert talent (sometimes!)

SQL JOINS are universally regarded as          It's MUCH easier to relate ORM Entity Objects than to build complex join queries.

In my webapps, where I am often working with a set of related objects, often I can interface with my high-level persistence layer using a single "anchor" object and selected relatives using an ORM, I can process them as detached objects, then toss them back to the persistence service layer as a unit (and a single transaction) instead of in parts like I would with raw DAOs. My DAOs are all lower down

Aside from saving wear and tear on programmers, ORMs are often more efficient than hand-coded SQL - I've seen benchmarks where ORMs performed twice as fast. That may not seem intuitive, but it parallels the experience with Assembly language versus high-level languages. Sure, you have more control, but it's also more work, and as you scale up, the cost of constantly rewriting code optimally with every change you make becomes prohibitive. A machine can rewrite - and re-optimize - code at the raw instruction level all day long at microsecond speeds and never get tired or make mistakes (bugs in the compiler don't count - they're other people's mistakes). AND as the current crop of JVMs has shown, a JIT code-writing environment can monitor for best/worst case and re-optimize on the fly based on workloads, whereas hard-coded optimizations are for better or worse, basically it.

Finally, there's cache. Raw JDBC/SQL offers little or no cache support. Some DBMS's such as PostgreSQL do have JDBC proxy servers that can cache for you, but not every DBMS is so well supported. Hibernate can do caching and work with external caching.

On the downside, an ORM is overkill for small projects. You have to spend extra time mapping entities, then the ORM itself is overhead. That's when I'd typically use SQL. It's when you start scaling up that ORMs begin to excel.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!