<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/improvement.gif" height="16" width="16" border="0" align="absmiddle" alt="Improvement"> <a style='color:#6c797f;text-decoration:none;' href='https://hibernate.onjira.com/browse/HHH-7841'>HHH-7841</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-7841'><strong>Redesign Loader</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>Great discussion with <a href="https://hibernate.onjira.com/secure/ViewProfile.jspa?name=gbadner" class="user-hover" rel="gbadner">Gail Badner</a> that I wanted to capture for posterity:</p>
<p><span class="error">[10:20]</span> <sebersole> ok, thanks<br/>
<span class="error">[10:20]</span> <sebersole> tieing in jpa entity graphs will be fun<br/>
<span class="error">[10:21]</span> <sebersole> one thought was to use a different visitor<br/>
<span class="error">[10:21]</span> <gbadner> yeah, I was thinking that<br/>
<span class="error">[10:21]</span> <sebersole> one that drives on the graph, not the model<br/>
<span class="error">[10:22]</span> <gbadner> iiuc, it needs to do both<br/>
<span class="error">[10:22]</span> <sebersole> you can only <b>drive</b> on one<br/>
<span class="error">[10:22]</span> <sebersole> drive means the main driver<br/>
<span class="error">[10:22]</span> <sebersole> you have to look at both sure<br/>
<span class="error">[10:22]</span> <sebersole> but thats not the same<br/>
<span class="error">[10:22]</span> <gbadner> I need to look at what you did for entity graphs in master<br/>
<span class="error">[10:23]</span> <sebersole> its the same split we have today in hql processing and normal walk/loaders<br/>
<span class="error">[10:23]</span> <gbadner> wimi, you need what's specified in the graph plus get the defaults from the model<br/>
<span class="error">[10:23]</span> <sebersole> i did nothing that effects this<br/>
<span class="error">[10:23]</span> <sebersole> sure<br/>
<span class="error">[10:23]</span> <sebersole> but there is a different between driving based on somethign and looking at something<br/>
<span class="error">[10:24]</span> <sebersole> i use driving as in the sql sense<br/>
<span class="error">[10:24]</span> <sebersole> the root thing<br/>
<span class="error">[10:24]</span> <sebersole> there is a reason hql, for example, does not honor mapping define dfetches<br/>
<span class="error">[10:24]</span> <sebersole> a practical reason i mean<br/>
<span class="error">[10:24]</span> <sebersole> aside from any philosophical reasons<br/>
<span class="error">[10:25]</span> <gbadner> hmm, didn't realize that<br/>
<span class="error">[10:25]</span> <sebersole> because you can only drivbe that on one set of data<br/>
<span class="error">[10:25]</span> <sebersole> in hql that is the explicit join fetches in the query<br/>
<span class="error">[10:25]</span> <sebersole> we possibly have the same condition here<br/>
<span class="error">[10:25]</span> <sebersole> but<br/>
<span class="error">[10:26]</span> <sebersole> there is a difference<br/>
<span class="error">[10:26]</span> <sebersole> we <b>could</b> (i think) still incorporate entity graphs using the model driven visitor<br/>
<span class="error">[10:26]</span> <sebersole> the eplicit fetches from the entity graph would be additional<br/>
<span class="error">[10:27]</span> <gbadner> yeah, I was thinking something like that<br/>
<span class="error">[10:27]</span> <sebersole> this has the added benefit that the main parts of the base loadplan could still get reused<br/>
<span class="error">[10:28]</span> <sebersole> we'd say that the entity graph can only add non-join fetches<br/>
<span class="error">[10:28]</span> <sebersole> which is actually more in-line with their intent anyway<br/>
<span class="error">[10:28]</span> <gbadner> oh, I see; they'd be follow on fetches<br/>
<span class="error">[10:28]</span> <sebersole> true the spec does not say how the fetches need to happen...<br/>
<span class="error">[10:29]</span> <sebersole> but the whole graph stuff cam about because of people not being happy with hql/jpql join fetches<br/>
<span class="error">[10:29]</span> <sebersole> right<br/>
<span class="error">[10:29]</span> <sebersole> they'd be batch or ...<br/>
<span class="error">[10:29]</span> <sebersole> still done IMMEDIATELY<br/>
<span class="error">[10:29]</span> <sebersole> but subsequent<br/>
<span class="error">[10:29]</span> <gbadner> right<br/>
<span class="error">[10:30]</span> --> galderz has joined this channel (~galder@redhat/jboss/galderz).<br/>
<span class="error">[10:30]</span> <sebersole> have you had a chance to peek at the resultset processor stuff?<br/>
<span class="error">[10:30]</span> <sebersole> thats the crux<br/>
<span class="error">[10:30]</span> <gbadner> no, that's next<br/>
<span class="error">[10:30]</span> <sebersole> ok<br/>
<span class="error">[10:30]</span> <gbadner> is there a test for that?<br/>
<span class="error">[10:30]</span> <sebersole> no, not yet<br/>
<span class="error">[10:31]</span> <sebersole> because its really still in dev<br/>
<span class="error">[10:31]</span> <gbadner> where's a good place to start with that?<br/>
<span class="error">[10:31]</span> <sebersole> whatever the main impl is<br/>
<span class="error">[10:31]</span> <sebersole> ResultSetProcessorImpl i think its called<br/>
<span class="error">[10:31]</span> <sebersole> the ScrollableResultSetProcessorImpl stuff is conceptual atm<br/>
<span class="error">[10:32]</span> <sebersole> another option is to move the building of those to LoadPlan<br/>
<span class="error">[10:32]</span> <gbadner> ok, I see it<br/>
<span class="error">[10:32]</span> <sebersole> LoadPlan.buildResultSetProcessor() <br/>
<span class="error">[10:32]</span> <sebersole> LoadPlan.buildScrollableResultSetProcessor() <br/>
<span class="error">[10:32]</span> <sebersole> see how those "feel" while you look at it<br/>
<span class="error">[10:32]</span> <gbadner> yeah, that would make sense<br/>
<span class="error">[10:33]</span> <sebersole> in terms of the "reuse" stuff we discussed last night for loadplans...<br/>
<span class="error">[10:34]</span> <sebersole> we might want to consider ways to allow LoadPlans to be loosely equal<br/>
<span class="error">[10:35]</span> <sebersole> what i mean by that is to have a way to say that 2 loadplans, for example, are "equal" is they define the same set of join fetches<br/>
<span class="error">[10:35]</span> <sebersole> and then to offload the subsequent fetches somehere, since thats the part that is likely to vary<br/>
<span class="error">[10:35]</span> <sebersole> maybe chained loadplans?<br/>
<span class="error">[10:36]</span> <gbadner> yeah<br/>
<span class="error">[10:36]</span> <sebersole> dunno exactly<br/>
<span class="error">[10:36]</span> <sebersole> but something to think through<br/>
<span class="error">[10:36]</span> <gbadner> well, maybe not chained, just sequential<br/>
<span class="error">[10:36]</span> <sebersole> ideall the more often we can reuse the loadplans the better<br/>
<span class="error">[10:36]</span> <gbadner> yeah, the more granular, the better<br/>
<span class="error">[10:36]</span> <sebersole> +1000<br/>
<span class="error">[10:37]</span> <sebersole> heres maybe another way to look at it<br/>
<span class="error">[10:37]</span> <gbadner> I can see the follow on load plans being simple building blocks<br/>
<span class="error">[10:37]</span> <gbadner> more a matter of assembling them<br/>
<span class="error">[10:37]</span> <sebersole> well<br/>
<span class="error">[10:38]</span> <sebersole> the difficulty there is still this notion of paths<br/>
<span class="error">[10:38]</span> <sebersole> the loadplan, as is, maintains that because the fetches (all kinds) are still "in path"<br/>
<span class="error">[10:39]</span> <sebersole> the difference really all comes down to ResultSetProcessor<br/>
<span class="error">[10:39]</span> <sebersole> and the fact that we might have to perform additional selects here, versus there<br/>
<span class="error">[10:40]</span> <gbadner> is "fetch depth" defined by jpa?<br/>
<span class="error">[10:40]</span> <sebersole> still thinking about the entity graph case here<br/>
<span class="error">[10:40]</span> <sebersole> not sure what you mean by jpa and "fetch depth"<br/>
<span class="error">[10:40]</span> <sebersole> anyway<br/>
<span class="error">[10:40]</span> <gbadner> oh, I guess that would be more of an implementation detail<br/>
<span class="error">[10:41]</span> <sebersole> what i am trying to plan through is that it sure would be nice to have entity graphs work such that...<br/>
<span class="error">[10:41]</span> <gbadner> anything that exceeds it would be follow-on<br/>
<span class="error">[10:41]</span> <sebersole> we use the same loadplan whether there is a entity graph in play or not<br/>
<span class="error">[10:42]</span> <sebersole> the difference is that the graph simply defines additonal subsequent fetches<br/>
<span class="error">[10:42]</span> <sebersole> which really effects just the ResultSetProcessor<br/>
<span class="error">[10:42]</span> <sebersole> this is part of that code I have not fleshed out yet<br/>
<span class="error">[10:43]</span> <gbadner> ResultSetProcessor isn't 1:1 w/ LoadPlan?<br/>
<span class="error">[10:43]</span> <sebersole> but the basic idea is that ResultSetProcessor would need a way to let each subsequent select know about the matching key found for each row <br/>
<span class="error">[10:44]</span> <sebersole> thats to be decided<br/>
<span class="error">[10:44]</span> <sebersole> if we go the LoadPlan.buildResultSetProcessor() route<br/>
<span class="error">[10:44]</span> <sebersole> the decision point is whether the ResultSetProcessor is stateful<br/>
<span class="error">[10:45]</span> <sebersole> but<br/>
<span class="error">[10:45]</span> <sebersole> the important point in either case<br/>
<span class="error">[10:45]</span> <sebersole> is that given a LoadPlan I can get a delegate capable of reading the results from a result set with the shape described by that plan<br/>
<span class="error">[10:46]</span> <sebersole> i dont care really whether there are multiple physical instances<br/>
<span class="error">[10:46]</span> <sebersole> or one per loadplan<br/>
<span class="error">[10:46]</span> <sebersole> thats not important to me<br/>
<span class="error">[10:46]</span> <sebersole> li think having them statefukl could be useful<br/>
<span class="error">[10:47]</span> <sebersole> we could get rid of the LoadContexts stuff<br/>
<span class="error">[10:47]</span> <gbadner> that would be nice<br/>
<span class="error">[10:47]</span> <sebersole> since the entity and collection load context reall would be the stateful resultsetprocessor<br/>
<span class="error">[10:48]</span> <sebersole> we'd need to be able to chain those though<br/>
<span class="error">[10:48]</span> <-- DavideD has left this server (Ping timeout: 272 seconds).<br/>
<span class="error">[10:48]</span> <sebersole> hopefully that makes sense<br/>
<span class="error">[10:48]</span> --> hardy has joined this channel (~hardy@redhat/jboss/hardy).<br/>
<span class="error">[10:49]</span> <gbadner> I'm thinking about what "chaining" means<br/>
<span class="error">[10:49]</span> <sebersole> well subsequent selects...<br/>
<span class="error">[10:49]</span> <sebersole> so you are processing a row from the result set that has Employee#1<br/>
<span class="error">[10:49]</span> <gbadner> I can see that a ResultSetProcessor would get some input (e.g., ID) for loading<br/>
<span class="error">[10:49]</span> <sebersole> and Employee's Address was not join fetched<br/>
<span class="error">[10:50]</span> <sebersole> so you need to get their Address<br/>
<span class="error">[10:50]</span> <gbadner> yep, got it<br/>
<span class="error">[10:50]</span> <sebersole> ok<br/>
<span class="error">[10:51]</span> <sebersole> now if only sannegrinovero would hurry and get done with that ast work...<br/>
<span class="error">[10:51]</span> <sebersole> <img class="emoticon" src="https://hibernate.onjira.com/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/><br/>
<span class="error">[10:51]</span> <gbadner> but still, a LoadPlan/ResultSetProcessor could be very granular; just needs some input<br/>
<span class="error">[10:51]</span> <sebersole> yep<br/>
<span class="error">[10:51]</span> <sebersole> i think the real decision at the moment<br/>
<span class="error">[10:51]</span> <sebersole> is<br/>
<span class="error">[10:51]</span> <sebersole> how to tie entity graphs in<br/>
<span class="error">[10:52]</span> <sebersole> is that a different loadplan?<br/>
<span class="error">[10:52]</span> <sebersole> or<br/>
<span class="error">[10:52]</span> <sebersole> is the ResultSetProcessor simply sensitive to defined graphs<br/>
<span class="error">[10:53]</span> <sebersole> what i envision inside ResultSetProcessor for subsequent fetches is important there i guess<br/>
<span class="error">[10:53]</span> <sebersole> since i dont think that code is in place yet<br/>
<span class="error">[10:53]</span> <sebersole> but<br/>
<span class="error">[10:53]</span> <sebersole> going back to the Employee/Address example<br/>
<span class="error">[10:54]</span> <-- hardy has left this server (Ping timeout: 252 seconds).<br/>
<span class="error">[10:54]</span> <sebersole> the general idea was that ResultSetProcessor would use the EntityReturn to read the Employee data<br/>
<span class="error">[10:55]</span> <sebersole> EntityReturn sees that it has a Fetch for Address<br/>
<span class="error">[10:55]</span> <sebersole> so it would either (a) register that "address key" with the EntityFetch<Address><br/>
<span class="error">[10:55]</span> <sebersole> or<br/>
<span class="error">[10:55]</span> <sebersole> (b) ask the EntityFetch<Address> to go ahead and load itself<br/>
<span class="error">[10:56]</span> --> hardy has joined this channel (~hardy@redhat/jboss/hardy).<br/>
<span class="error">[10:56]</span> <sebersole> (b) is closer to what we do today<br/>
<span class="error">[10:56]</span> <sebersole> (a) would allow better use of batch loading for handling select fetches<br/>
<span class="error">[10:57]</span> <sebersole> well not even better...<br/>
<span class="error">[10:57]</span> <sebersole> it would allow use of it period<br/>
<span class="error">[10:57]</span> <gbadner> digesting...<br/>
<span class="error">[10:57]</span> <-- emmanuel-iThing has left this server (Quit: emmanuel-iThing).<br/>
<span class="error">[10:57]</span> <sebersole> its a bit tyo follow<br/>
<span class="error">[10:58]</span> <gbadner> "address key" would be the employee ID?<br/>
<span class="error">[10:58]</span> <gbadner> or whatever to identify the employee's address(es)<br/>
<span class="error">[10:59]</span> <gbadner> are you saying (b) would be a join fetch?<br/>
<span class="error">[10:59]</span> <sebersole> "address key" would depend on the fk defined<br/>
<span class="error">[10:59]</span> <gbadner> ok<br/>
<span class="error">[11:00]</span> <sebersole> assumign a normal many-to-one, no it would be the addr_id value<br/>
<span class="error">[11:00]</span> <sebersole> no, (b) is a subsequent select<br/>
<span class="error">[11:00]</span> <sebersole> select * from employee where ...<br/>
<span class="error">[11:01]</span> <sebersole> select * from address where id = ?<br/>
<span class="error">[11:01]</span> <sebersole> again, thats depends on the definition for Address<br/>
<span class="error">[11:02]</span> <sebersole> but asssuming a non-join, non-lazy association thats what it qwould mean above<br/>
<span class="error">[11:02]</span> <gbadner> yes, the address fetch would be follow-on<br/>
<span class="error">[11:03]</span> <sebersole> but<br/>
<span class="error">[11:03]</span> <sebersole> what could be a nice improvement here...<br/>
<span class="error">[11:03]</span> <sebersole> is to delay loading that Address until after all rows have been processed<br/>
<span class="error">[11:04]</span> <sebersole> and use "batch fetch" approach<br/>
<span class="error">[11:04]</span> <sebersole> i say "batch fetch" approach because its not technically a batch fetch<br/>
<span class="error">[11:04]</span> <gbadner> yes, that would definitely simplify the processing<br/>
<span class="error">[11:04]</span> <sebersole> we are just using the same sql and ResultSetProcessor we would have used for a batch fetch of Address<br/>
<span class="error">[11:05]</span> <sebersole> wel not just simply<br/>
<span class="error">[11:05]</span> <sebersole> its woud be a huge perf gain<br/>
<span class="error">[11:05]</span> <gbadner> right, that's a whole lot simpler<br/>
<span class="error">[11:06]</span> <sebersole> anyway, things to keep in mind<br/>
<span class="error">[11:06]</span> <gbadner> I've spent a <b>lot</b> of time in that loader code<br/>
<span class="error">[11:06]</span> <sebersole> as thats not there<br/>
<span class="error">[11:06]</span> <sebersole> yes its confusing<br/>
<span class="error">[11:06]</span> <gbadner> very<br/>
<span class="error">[11:06]</span> <sebersole> it has all the stuff i dont like<br/>
<span class="error">[11:07]</span> <sebersole> parallel arrays, subclassing out the whazoo<br/>
<span class="error">[11:07]</span> <gbadner> have you thought about caching results/loadplans?<br/>
<span class="error">[11:07]</span> <sebersole> wdym?<br/>
<span class="error">[11:07]</span> <sebersole> you mean the query cache?<br/>
<span class="error">[11:07]</span> <gbadner> yeah<br/>
<span class="error">[11:07]</span> <sebersole> a little<br/>
<span class="error">[11:08]</span> <sebersole> would be <b>nice</b><br/>
<span class="error">[11:08]</span> <sebersole> but i dont consider it a priority<br/>
<span class="error">[11:08]</span> <sebersole> having a loadplan makes it more doable<br/>
<span class="error">[11:09]</span> <sebersole> since you have a singular repsentation of the "shape"</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 -->