<style>
/* Changing the layout to use less space for mobiles */
@media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) {
    #email-body { min-width: 30em !important; }
    #email-page { padding: 8px !important; }
    #email-banner { padding: 8px 8px 0 8px !important; }
    #email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; }
    #email-fields { padding: 0 8px 8px 8px !important; }
    #email-gutter { width: 0 !important; }
}
</style>
<div id="email-body">
<table id="email-wrap" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f0f0f0;color:#000000;width:100%;">
    <tr valign="top">
        <td id="email-page" style="padding:16px !important;">
            <table align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;border:1px solid #bbbbbb;color:#000000;width:100%;">
                <tr valign="top">
                    <td bgcolor="#3e4c4e" style="background-color:#3e4c4e;color:#ffffff;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;line-height:1;"><img src="https://www.jboss.org/dms/hibernate/images/jira/jiraheader_hibernate.png" alt="" style="vertical-align:top;" /></td>
                </tr><tr valign="top">
    <td id="email-banner" style="padding:32px 32px 0 32px;">

                
        
        
            <table align="left" border="0" cellpadding="0" cellspacing="0" width="100%" style="width:100%;">
    <tr valign="top">
        <td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;padding:0;">
                                        <img id="email-avatar" src="https://hibernate.onjira.com/secure/useravatar?ownerId=steve&avatarId=10346" alt="" height="48" width="48" border="0" align="left" style="padding:0;margin: 0 16px 16px 0;" />
                        <div id="email-action" style="padding: 0 0 8px 0;font-size:12px;line-height:18px;">
                                    <a class="user-hover" rel="steve" id="email_steve" href="https://hibernate.onjira.com/secure/ViewProfile.jspa?name=steve" style="color:#6c797f;">Steve Ebersole</a>
     commented on <img src="https://hibernate.onjira.com/images/icons/newfeature.gif" height="16" width="16" border="0" align="absmiddle" alt="New Feature"> <a style='color:#6c797f;text-decoration:none;' href='https://hibernate.onjira.com/browse/HHH-5187'>HHH-5187</a>
            </div>
                        <div id="email-summary" style="font-size:16px;line-height:20px;padding:2px 0 16px 0;">
                <a style='color:#6c797f;text-decoration:none;' href='https://hibernate.onjira.com/browse/HHH-5187'><strong>Allow some control over whether or not an association is loaded via a join on the merge path</strong></a>
            </div>
                    </td>
    </tr>
</table>
    </td>
</tr>
<tr valign="top">
    <td id="email-fields" style="padding:0 32px 32px 32px;">
        <table border="0" cellpadding="0" cellspacing="0" style="padding:0;text-align:left;width:100%;" width="100%">
            <tr valign="top">
                <td id="email-gutter" style="width:64px;white-space:nowrap;"></td>
                <td>
                    <table border="0" cellpadding="0" cellspacing="0" width="100%">
                        <tr valign="top">
    <td colspan="2" style="color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;padding:0 0 16px 0;width:100%;">
        <div class="comment-block" style="background-color:#edf5ff;border:1px solid #dddddd;color:#000000;padding:12px;"><p>The concern over what Hibernate does here today is essentially a question of context.  Hibernate creates and caches a load-for-merge SQL string "up front" when the <tt>SessionFactory</tt>/<tt>EntityManagerFactory</tt> is being built.  Again, there are real performance reasons we do it this way; but here people are specifically asking to circumvent those performance optimizations.  So first, I wanted to (re)explain there optimization here.</p>

<p>Consider a simple domain model of a <tt>Customer</tt>, <tt>Order</tt> and <tt>LineItem</tt>.  And lets assume that merge cascading is enabled on <tt>Customer.orders</tt> and <tt>Order.lineItems</tt>.  At start up, Hibernate will create and cache a SQL SELECT statement for loading a <tt>Customer</tt> on merge in the detached case; that SQL SELECT will "join fetch" <tt>Customer.orders</tt> and <tt>Order.lineItems</tt> because of the merge cascading.  The performance gain here is 2-fold, though mostly related to avoiding the sending of multiple commands to the database.  </p>

<p>However, lets consider if we really honored the idea of not loading uninitialized associations on merge.  So first and foremost, this would not allow us to use the pre-cached SQL SELECT because now we are performing a more contextual execution plan.  So when we receive the <tt>merge(customer)</tt> call, we now have to actually walk its association tree to determine:</p>
<ol>
        <li>whether it is ok to use the pre-cached SQL SELECT based on the initialized/uninitialized state of the merge graph.  So here we need to check <tt>customer.getOrders()</tt>, and assuming that is initialized, for each order we need to check <tt>order.getLineItems()</tt>.</li>
        <li>in the case of any of those check finding non-initialized state we cannot use the pre-cached SQL SELECT; so we have to do "something else" which could be either:
        <ol>
                <li>build a modified "join fetch" SQL on the fly</li>
                <li>don't try to "join fetch" at all and just use n+1 selects to load the merge graph</li>
        </ol>
        </li>
</ol>


<p>And even in the case of walking the association tree and determining that it is in fact ok to use the pre-cached SQL SELECT, we have still incurred the overhead of walking the tree to decide that.  I almost think that, for the users wanting this, there is actually not any benefit to having the load-for-merge SQL include join fetches at all.  To the point where, maybe there is just a <tt>SessionFactory</tt>-wide switch that says whether to build join fetches into the pre-cached load-for-merge SQL statements.</p>


<p>My concern with an approach like <tt>@SkipJoinLoadOn</tt> is that at the end of the day we still have a non-contextual strategy.  The to-be-cached SQL SELECT would just <b>never</b> include the annotated association.  Another similar option would be to have a more contextual targetted annotation (maybe <tt>@SkipJoinLoadIfUninitialized</tt>).  </p></div>
        <div style="color:#505050;padding:4px 0 0 0;">                </div>
    </td>
</tr>
                    </table>
                </td>
            </tr>
        </table>
    </td>
</tr>













            </table>
        </td><!-- End #email-page -->
    </tr>
    <tr valign="top">
        <td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:10px;line-height:14px;padding: 0 16px 16px 16px;text-align:center;">
            This message is automatically generated by JIRA.<br />
            If you think it was sent incorrectly, please contact your JIRA administrators<br />
            For more information on JIRA, see: <a style='color:#6c797f;' href='http://www.atlassian.com/software/jira'>http://www.atlassian.com/software/jira</a>
        </td>
    </tr>
</table><!-- End #email-wrap -->
</div><!-- End #email-body -->