As shown in some of the previous Hibernate examples, the query
generated by Hibernate is:
Select
employee0_.id as id1_3_0_,
employee0_.name as name2_3_0_,
companymap1_.EMPLOYEE_ID as EMPLOYEE_ID3_3_1_,
companymap1_.id as id1_1_1_,
companymap1_.id as formula0_1_,
companymap1_.id as id1_1_2_,
companymap1_.EMPLOYEE_ID as EMPLOYEE_ID3_1_2_,
companymap1_.MANAGER_ID as MANAGER_ID4_1_2_,
companymap1_.name as name2_1_2_,
manager2_.id as id1_5_3_,
manager2_.name as name2_5_3_,
jobs3_.EMPLOYEE_ID as EMPLOYEE_ID3_3_4_,
jobs3_.id as id1_4_4_,
jobs3_.id as formula1_4_,
jobs3_.id as id1_4_5_,
jobs3_.designation as designation2_4_5_,
jobs3_.EMPLOYEE_ID as EMPLOYEE_ID3_4_5_
from
EMPLOYEE employee0_
left outer join
COMPANY companymap1_
on employee0_.id=companymap1_.EMPLOYEE_ID
left outer join
MANAGER manager2_
on companymap1_.MANAGER_ID=manager2_.id
left outer join
JOB jobs3_
on employee0_.id=jobs3_.EMPLOYEE_ID
where
employee0_.id=?
Note that every column alias has some particular naming style like:
The reason for providing all the above information is to show that aliases generated by Hibernate are not random.
Each table gets a unique ID and every column gets a unique ID.
Due to this, Hibernate is able to join tables having similarly named columns (like Employee.name and Company.name).
The joinSuffix comes in handy when doing a self-join.
In a self-join, Table.uniqueInteger and Column.uniqueInteger would be same for both the tables.
So this extra suffix resolves that tie as well.
Final place where all this is mashed up is the following line in AbstractEntityJoinWalker.initStatementString()
Note that Table.uniqueInteger does depend on the order of POJO classes parsed by Hibernate.
So, in different JVMs, if this order is different, this field will be different in those tables and hence the aliases will also be different.
Also, the joinSuffix depends on the number of joins in a query.
So it varies from query to query and so do the aliases.
On a concluding note, the aliases generated in one JVM are same if the query remains the same. If you ever
see yourself concerning about databases not performing optimally because you suspect lot of alias generation
for the same query, take a dump of the queries and run sort -u on them.
The truth will be out and if aliases are indeed misbehaving, above code gives you the pointers to look into the code!
Got a thought to share or found a bug in the code? We'd love to hear from you: