A brief introduction to using SQL statements in the Java Hibernate framework _java

There are HQL query syntax in hibernate. But we are more familiar with the number of SQL statements, then how should we let hibernate support SQL? We don't have to think about it, the Hibernate team has already done it.
Nonsense not to say, directly to the example.

It's a SQL statement, it's nonsense, it's an individual knows. We want hibernate to execute this statement, what should we do? Look at the code:

Query query = session.createsqlquery ("select * from T_user usr"); 

In this way, the rest, we should all know, the usual inquiries.
What was the return after the enquiry?

while (Iter.hasnext ()) { 
 object[] Objs = (object[)) Iter.next (); 
 for (int i = 0; i < objs.length i++) { 
 System.out.print (objs[i]); 
 System.out.println (); 
} 

Each result returned is an object[] array,

Then someone ran out to say object-oriented. Yes, it's an object-oriented, alas, no way.
We continue to look at:

Select {usr.*} from T_user usr 

See here, estimate some children's shoes start chicken move, that curly braces what thing?
Don't worry, take it slow. Let's go ahead and look at the code.

Copy Code code as follows:

Query query = Session.createsqlquery ("Select {usr.*} from T_user usr"). addentity (Tuser.class);

What we see is different from the previous one, what do we mean by adding a addentity?
We have a direct API that sees such a bunch of explanations:

 Addentity
sqlquery addentity (String tablealias,
   Class EntityType)
Declare a "root" entity
Parameters :
tablealias-the SQL table alias
entitytype-the java type of the entity to add as a root

There is no one, a cup. You can only use your own hands.
The first parameter is the alias of the table, like the above statement, our table alias is usr, so the first argument is USR, and the second is the query to which the results need to map to which class, because we are in the mapping file through Tuser map to the T_user table, So here we are, of course, Tuser. Then a check, there are SQL statements out, and the results found are tuser type.
The results we found were:

Org.hibernate.tutorial.domain6.tuser@198cb3d 

Of course, your affirmation is not the same as mine. Don't move the chicken.

Maybe we don't need to find out all of this, and all we need to do is set an alias:

Select U.id as {usr.id},u.name as {Usr.name},u.age as {usr.age} from T_user u 

We saw that we used the as to specify the alias for the field, or the same in the program:

Copy Code code as follows:

Query query = Session.createsqlquery ("Select U.id as {usr.id},u.name as {Usr.name},u.age as {usr.age} from T_user u"). adde Ntity ("usr", tuser.class);

This is simple, not much to say.

As we've mentioned before, some teams will rule out the need to write SQL statements in code, which requires a configuration file.
We can add in the configuration file:

<sql-query name= "Querytuser" > 
 <return alias= "usr" entity-name= "org.hibernate.tutorial.domain6.TUser" /> 
 Select {usr.*} from T_user usr where name=:name 
</sql-query> 

Note that the entity-name here need to write a complete package name, or it will be an error. Here we have the child tag return, which specifies the alias and class name of the table, so that we do not need to addentity at runtime.
Look at the code:

Query query = session.getnamedquery ("Querytuser"); 
Query.setparameter ("name", "Shun"); 
List List = Query.list (); 

We're just going to be OK, and note that we're not adding addentity, mainly because of the configuration file.
Note that if you configure in a configuration file, you must have a return child label that specifies the table alias and class name. This is mainly to avoid the repetition of the judgment when we read the statement.


After all this time, we've been talking about aliases, so what if our table doesn't have aliases, but the results we want to return are encapsulated in the object?

select * from T_user usr 

Quite simply, just call Addentity's overloaded method Addentity (class Clazz), just provide a class name, not a table alias.

Of course, hibernate also supports stored procedures, only to set the Sql-query callable property to True in the configuration file means that the current call is stored procedures, due to the stored procedures I do not have much contact, the future study more and then with you study.

When we call Session.save and other corresponding methods for data manipulation, it translates into Hibernate built-in SQL statements, but what if we want to control the format of the SQL statements ourselves?
Hibernate actually thought of it.
We add directly to the mapping file:

<sql-insert> 
 INSERT INTO T_user (name,age) VALUES (?,?) 
 </sql-insert> 
 <sql-update> 
 update USER SET user_name=?,age=? WHERE user_id=? 

Note that this needs to be added to the class label as a child label. We are all capital letters here, in order to distinguish the default statement with Hibernate, no other meaning.
Let's take a look at the invocation of insert:

User user = new user (); 
User.setname ("shun123123"); 
User.setage (23); 

When we call save, the hibernate statement is:
Hibernate:

INSERT into USER (user_name,age) VALUES (?,?) 

It calls the statements within our configured Sql-insert tag.
Let's take another look at the call to update:

User user = (user) Session.get (user.class,new Long); 
User.setname ("shun123123"); 
User.setage (a); 
Session.save (user); 

We call the save, it will automatically invoke the update, at which point the statement is:
Hibernate:

UPDATE USER SET user_name=?,age=? WHERE user_id=? 

We see that the output statement is capitalized, that is, the statement we configured is invoked.

The DELETE statement is also the same configuration.