Hibernate is nothing but noise

The blog that won the ire of Christian Bauer. On it's one year anniversary. I'll be reposting it.

All noise less power. This is an SQL view written in Oracle as an example that can be queried by a JDBC in a no brainer manner:

   
        CREATE OR REPLACE VIEW V_DECIMAL AS 
        SELECT ((50000 / 1000) * .525) AS COMPUTATION FROM SYS.DUAL;
   

Now, let's query this view within SQLPlus or TOAD or TORA or Quantum or JFaceDbc or whatever SQL editor you have.

   
       SELECT * FROM V_DECIMAL;

And the output would be:

   
      +---------------------+
      |COMPUTATION          |
      +---------------------+
      |26.25                |
      +---------------------+
   

Now doing it in Hibernate will require a persistent object like this:

   
   public class VDecimal{
      
      Long computation;
      
      public VDecimal(){
      
      }
      
      //Since it's a view and 'computation' is not a real column, Hibernate does not have a clue if the actual datatype is a decimal or not.
      //So the mother of all screwups will think the most obvious data type.
      public void setComputation(java.lang.Long computation){
          
          this.computation = computation;
 
      }
      
      public Long getComputation(){
      
          return computation;
          
      }
   }
   
   

Of course that lousy VComputation.hbm.xml file is needed all the time that will look something like this:


<!--Since it's a view and "computation" is not a real column, Hibernate's dumb tools can't generate an id tag, sorry...-->
<property name="computation" (...the rest of here will probably be a generated guesswork)/>




Because of these I was tempted to "cheat" the ID tag, to lessen Hibernate's embarassing situation with an end-user and proceed to the querying code. What I chose were two styles, the "proper" way and the typical way:

       //"proper" way
       VDecimal vdec = null;
       Session session = creation session blah blah blah....;
       Query query = session.createQuery("from vdecimal in class VDecimal");
       Iterator iterate = query.iterate();
       while(iterate.hasMoreElements(){
           Obect tmp = iterate.next();
           vdec = (VDecimal)tmp;
       }
       System.out.println("I am supposed to show up: " + vdec.getComputation());
       
       
       //the typical way:
       List letse = session.find("from VDecimal decimal");
       vdec = (VDecimal)letse.get(0);
       System.out.println("Chances are this might show up: " + vdec.getComputation());
   

Using a Query interface, the above will return a decimal but for the lack of foresight will throw "QueryException: invalid alias 26.....".

Since we might be stupid enough and can't fix it then what the heck it's a step backward anyway. So much with this sad story but before some Pampers Kids will criticize SQL views here, this is what I am going to tell you. For the nth time, this is a pathetic struggle to avoid SQL tweaking. For decades, views has been fixing complex table joins, they can break it down into smaller set of relevant queries to create hundreds relevant virtual tables that does not require unloading and reloading everytime it is accessed and RDBMS like Oracle and PostgreSQL can perform this in a snap. I watch in aweful disappointment on my Tomcat logs the "binding and mapping" dance Hibernate does for a simple query even if its only during first run. And I watch in aweful disgrace when I see others will almost kneel and kiss the ground when they see this dance happening over and over again.Torque, I might say is a bit simpler, once you've created your persistent objects, there's no need to reference the XML document that was configured to build the schema and the class that was mapped to it. But so much with this O/R Mapping crap.

Of course, the same old rule is still in force: "If your data structure is a screw up, your application is no different". Hibernate is not an excuse to have lousy database design, it will not reverse a database design failure. An application with a good DB foundation will run seamlessly with or without Hibernate. Views and if necessary, stored procedures and functions still packs some power punches, so learn to use them and learn to love them. Why be worried from "learning" something else aside from Java alone? Because this is the only consistent excuse I've heard and read from O/R mapping advocates. Very shallow reason.


All in all, JDO ROCKS! DAO Pattern Rocks!