[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2449?page=c...
]
radhakrishna commented on HHH-2449:
-----------------------------------
Thought that this is a very simple scenario that might have already been addressed,
discussed and take care of in Hibernate as it involves serious performance issues.
Posted on Hibernate forums made me realize that lazy is only possible from the side
holding the foreign key which makes sense and a work around by defining the one-to-one as
a <set>
But how can the child loads eagerly in separate select statements rather than using a join
for no reason! The concept of lazy="no-proxy" and lazy="proxy" are
confusing. The lazy="no-proxy" in the documentation suggests enabling lazy
fetching with out proxies as the only way to have the <one-to-one> end not load
eagerly. But it requires byte-code manipulation as described here:
http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#p....
I had no idea how to do this as I could not find an example or a way to do it.
Again, to explain my scenario: I have a user and user_termination tables with only the
user_termination having the user_id as the foreign key and the user may or may not have a
user_termination entry!
I defined the userTermination mapping in user as
<one-to-one name="userTermination" class="UserTermination"
property-ref="user" lazy="no-proxy">
</one-to-one>
And the userTermination has a user entry as a many-to-one
<many-to-one name="participant" class="Participant"
column="participant_id" unique="true" not-null="false"
/>
I chose lazy="no-proxy" in my parent however, whenever I write my HQL on parent
User table such as
from User user where user.user_deleted_date_time is null
it fetches all of my user's first in a single select and then follows by a separate
select statements of userTermination, obviously whenever they may only exist, although I
don't need them to be fetched eagerly unless I do a left join fetch or something!
There is no alternative by avoiding the userTermination entry in user object and write my
HQL query as select from user, userTermination where
user.userId = userTermination.userId it looses the user objects as only not all users have
userTermination!!
In a normal SQL statement all I have to do is a left join as in
select .. from user, userTermination where user.userId = userTermination.userId(+)
I am not sure if I can write my left join HQL query without having it to be mentioned as a
one-to-one object in my parent mapping?
Lazy loading for one-to-one asociations
---------------------------------------
Key: HHH-2449
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2449
Project: Hibernate Core
Issue Type: New Feature
Components: core
Affects Versions: 3.2.2
Environment: Hibernate 3.2.2
Reporter: jose
After read "Some explanations on lazy loading" and my tests I found a lossing
feature in Hibernate (3.2.2).
one-to-one with lazy="proxy"_____________________________________________
Hibernate ALWAYS launch selects to know if one-to-one is null or can be proxied.
one-to-one with lazy="no-proxy"__________________________________________
Instrumentation allows to hibernate modify the getter to allows lazy loading on
demand:
* but allways initialize ALL no-proxy relations (with first getter call)
-> must initialize ONLY the requested property
* never auto-initialize FETCH joins, ALWAYS doit on demand (if opened session)
-> must auto-initialize ONLY the FETCHED property
note: Can submit a fix for this? How?
NEW FEATURE: one-to-one with lazy="proxy" without multiple SELECTS______
If Hibernate adds join, for all one-to-one relations, to get the foreign-key of other
tables, can check it to create a proxy or null.
note: that hibernate adds joins for hierarchy, why not for one-to-one relations?
This solution avoids:
* 'multiple subselects' after first select
* 'instrumentation' of bytecode
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira