• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate Tips: Usage

 
Ranch Hand
Posts: 171
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Author & Course Creator
Posts: 92
5
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 171
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you.
 
Greenhorn
Posts: 17
Slackware Flex Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic