Native SQL
You may also express queries in the native SQL dialect of your database. This is useful if you
want to utilize database specific features such as the CONNECT keyword in Oracle.
This also allows for a cleaner migration path from a direct SQL/JDBC based application to
Hibernate.
Hibernate3 also supports native SQL statements for all create, update, delete, and load
operations.
Creating a SQL based Query
SQL queries are exposed through the same Query interface, just like ordinary
HQL queries. The only difference is the use of Session.createSQLQuery().
The three parameters provided to createSQLQuery() are:
the SQL query string
a table alias name
the persistent class returned by the query
The alias name is used inside the sql string to refer to the properties of the mapped class
(in this case Cat). You may retrieve multiple objects per row by supplying
a String array of alias names and a Class array of
corresponding classes.
Alias and property references
The {cat.*} notation used above is a shorthand for "all properties". You
may even list the properties explicity, but you must let Hibernate provide SQL column aliases
for each property. The placeholders for these column aliases are the property name qualified by
the table alias. In the following example, we retrieve Cats from a different
table (cat_log) to the one declared in the mapping metadata. Notice that we
may even use the property aliases in the where clause.
Note: if you list each property explicitly, you must include all
properties of the class and its subclasses!
Named SQL queries
Named SQL queries may be defined in the mapping document and called in exactly the same way
as a named HQL query.
SELECT {person}.NAME AS {person.name},
{person}.AGE AS {person.age},
{person}.SEX AS {person.sex}
FROM PERSON {person} WHERE {person}.NAME LIKE 'Hiber%'
]]>
Custom SQL for CUD
Hibernate3 can use custom SQL statements for create, update, and delete operations.
The class and collection persisters in Hibernate already contain a set of configuration
time generated strings (insertsql, deletesql, updatesql etc.). The mapping tags
<sql-insert>, <sql-delete>, and
<sql-update> override these strings:
INSERT INTO PERSON (NAME, ID) VALUES ( UPPER(?), ? )
UPDATE PERSON SET NAME=UPPER(?) WHERE ID=?
DELETE FROM PERSON WHERE ID=?
]]>
The SQL is directly execute in your database, so you are free to use any dialect
you like.
Stored procedures are support if the callable attribute is set:
{call createPerson (?, ?)}
{? = call deletePerson (?)}
{? = call updatePerson (?, ?)}
]]>
The stored procedures are in most cases (read: better do it than not) required to
return the number of rows inserted/updated/deleted, as Hibernate has some runtime
checks for the success of the statement. Hibernate always registers the first statement
parameter as a numeric output parameter for the CUD operations:
Custom SQL for loading
You may also declare your own SQL (or HQL) queries for entity loading:
SELECT NAME AS {p.name}, ID AS {p.id} FROM PERSON WHERE ID=? FOR UPDATE
]]>
This is just a named query declaration, as discussed earlier. You may reference this
named query in a class mapping:
]]>
TODO: Document synchronized mapping element in named queries