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 <literal>Query</literal> 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