Hibernage query language is similar to the sql. One of the advantages of using the ORM tools is to be transparent to the database and the developed application should be independent of any changes made to the database. How is the hibernate query language independent of the database layout. If we are using hibernate queries in our application extensively, if we happened to modify the table structures in our database, we defnitely have to revisit our application to review or modify the hibernate queries. So how is it different from using plain SQL and JDBC in our application? Am I missing something here?
How is the hibernate query language independent of the database layout
It is not. Think about what you are asking - how can you write any query against a mutable structure, without including the need to change the query structure as required? What Hibernate gives you with HQL is a common language between database types, since not all DBs are fully ANSI92 compliant, and most contain many proprietory variations to SQL.
Thanks for your input Paul. As I understand from what you say, HQL provides a common language so independent of different databases. But most applications normally deal with one DB. In this case, what is the advantage of HQL. In fact, i see using this is more overhead as I see HQL is not as simple as SQL and it has to be learnt again. Any changes to the database, has to be propagated to the xml files, then the POJO objects, and then to your code. It looks tedious. And I am not seeing many advantages here. And looks like Torque is more simpler to learn and use than Hibernate. Hibernate on its own cannot do whole lot of things. We need to use Middlegen, AndroMedea etc etc. I think with torque, it is just one tool.
Joined: Sep 13, 2002
Here is one simple example of the type of vendor transparency benefits Hibernate offers over standard JDBC code: How do you limit the number of rows returned by a query? SQLServer says you need to add the clause "top". Informix says you need to add the clause "first". Other vendors require "limit". So, one of the many goals/advantages of Hibernate is that you do not need to concern yourself with the subtle syntax differences between different db vendors. You learn one language - HQL. That means that you can easily switch from SQLServer to Oracle without having to change any of your HQL code!
Of course vendor-transparency is just one advantage of using Hibernate. Another big advantage is that you simply don't have to worry about writing the JDBC code yourself - Hibernate does it for you in the background. Instead you can concentrate on building your business objects. And your business objects are mapped to your db schema using XML config files so changing your table structure may require nothing more than modifying the XML file. Depending on the changes you make to your table, you may have to change your business object, but like the previous poster stated, you can't help that no matter what persistence mechanism you choose.
Here's another example to help drive home the point. Let's say you add a new column into your table: A) JDBC way
Add the new field into your business object
Modify your JDBC method that performs the "select" in order to include the new column
Modify your JDBC method that performs the "insert" in order to add a new value into the new column.
Modify your JDBC method that performs the "update" in order to update an existing value in your new column
B) Hibernate way
Add the new field into your business object
Modify the Hibernate XML mapping file to include the new column
Blake Minghelli<br />SCWCD<br /> <br />"I'd put a quote here but I'm a non-conformist"
Well Krishna Radha, if you are certain you will only use one DB then Hibernate probably is overkill. But then with one DB any ORM is possibly overkill. As for most applications only using one DB, my experience is more mixed - about half of the apps I've worked on were pretty much tied to an RDBMS, but others were multiplatform. And sooner or later you will probably come across the immensely dull process of getting an app off an unsupported legacy DB platorm. If you've ever had to do that, its unlikely you would consider a Java-RDBMS app without a good ORM layer.
I can't speak for Torque - since I've never used it. But don't dismiss Hibernate off hand. Of all the ORM's I've used, it is one of the best, something which I think is reflected in all the positive comments about Hibernate you find out there. There are easy tools avaliable with Hibernate to automate the generation of mappings etc. - any of which can be used, but none are required as you suggect. The bare mimimum to get going with Hibernate a few jar files, your JDBC driver and some mapping files. I can't think of a much more straightforward way to implement an ORM layer. [ June 07, 2004: Message edited by: Paul Sturrock ]
Joined: Feb 12, 2003
I think Hibernate can be useful even if you are committed to one database platform. Writing the data access code that executes queries and unpacks the results into objects can be timeconsuming and error-prone. These mapping tools do all that for you.
Joined: Aug 30, 2001
Here's another example to help drive home the point. Let's say you add a new column into your table:
A) JDBC way Add the new field into your business object Modify your JDBC method that performs the "select" in order to include the new column Modify your JDBC method that performs the "insert" in order to add a new value into the new column. Modify your JDBC method that performs the "update" in order to update an existing value in your new column
B) Hibernate way Add the new field into your business object Modify the Hibernate XML mapping file to include the new column
In the second case, dont we need to modify the code that does the Insert or update to the table for setting value to the new column? In the case B as well we need to take care of everything as the case A (JDBC way).
Not exactly. When you "select" from HQL, the mapping file dictates what properties an object has, and Hibernate reflects through the POJO to call the setter methods for this object. So no code is added to include the new property if it is read only. It is of course different if it isn't, but that is the same in any language.
Joined: Mar 06, 2001
Originally posted by Krishna Radha:
In the second case, dont we need to modify the code that does the Insert or update to the table for setting value to the new column?
I started learning hibernate today and i too was wondering about the need for orm. Krishna tell me this, what is likely to be less buggier..modifying the insert, update and select calls in the sql or invoking a set or a get on a typed java object.