[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (HHH-2896) unified approach for id and natural-id loading

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43748#comment-43748 ] 

Steve Ebersole edited comment on HHH-2896 at 9/27/11 5:24 PM:
--------------------------------------------------------------

Caching will require care.  Is special handling for persistence context needed?

{quote}
<sebersole> now far and away the hardest part of implementing this will be caching
<sebersole> both
<sebersole> and
<EricDalquist> right, since the whole point of natural id lookups is better caching behavior
<sebersole> if we leave NaturalIdLoadAccess#getReference() we also need proxies to understand this
<sebersole> unless we "partially resolve" the natural key
<sebersole> thats probably the better option\
<sebersole> actually thats the only real option
<sebersole> we will need to cross-reference the natural key
<sebersole> to build the proxy
<sebersole> EricDalquist: still on board?
<EricDalquist> and this is where I'm a little more lost. My understanding right now is that the naturalid query looks in the query cache for data and then in the 2nd level cache for the partially-assembled object data
<EricDalquist> and if I'm following when you say "cross-reference the natural key" you're meaning we need to have some cache of "natural id" -> pk
<EricDalquist> and then we use to pk to load the actual object
<sebersole> well basically what it does (or tries to do) is to handle this cross ref
<sebersole> thats the "looks in the query cache" bit
<sebersole> EricDalquist: exactly what i mean
<EricDalquist> so are you thinking a whole new cache or continuing to essentially overload the query cache?
<sebersole> i'd opt for a whole new cache
<sebersole> using the query cache for this purpose causes problems
<EricDalquist> I would too from an implementers pov, then I can tune it separately from the query cache
<sebersole> that too
<sebersole> like you may or may not want to distribute this cached data
<EricDalquist> right
<sebersole> whereas thats frowned upon for query results
<sebersole> but even more basic, i meant it lets you better handle invalidating the entries
<EricDalquist> yup
<EricDalquist> especially if we can just store the base primitives involved in the natural id and pk
<sebersole> you *have* to in fact
<EricDalquist> right, I remember seeing the bug a while back about cache keys having references to assembled objects  :/
<EricDalquist> so the workflow would look like: Lookup pk from NaturalIdCache, On hit load object by PK
<sebersole> yes, you have to dissassemble the values
<EricDalquist> or: Lookup pk from NaturalIdCache, On miss query for pk by naturalid?
<EricDalquist> for that on-miss logic would the code just go through the normal query generation code path?
<sebersole> Lookup correlated pk from NaturalIdCache.  on miss, query db for related key, add to cache.  load by pk
{quote}

      was (Author: steve):
    Caching will require care.  Is special handling for persistence context needed?

{quote}
<sebersole> now far and away the hardest part of implementing this will be caching
<sebersole> both
<sebersole> and
<EricDalquist> right, since the whole point of natural id lookups is better caching behavior
<sebersole> if we leave NaturalIdLoadAccess#getReference() we also need proxies to understand this
<sebersole> unless we "partially resolve" the natural key
<sebersole> thats probably the better option\
<sebersole> actually thats the only real option
<sebersole> we will need to cross-reference the natural key
<sebersole> to build the proxy
<sebersole> EricDalquist: still on board?
<EricDalquist> and this is where I'm a little more lost. My understanding right now is that the naturalid query looks in the query cache for data and then in the 2nd level cache for the partially-assembled object data
<EricDalquist> and if I'm following when you say "cross-reference the natural key" you're meaning we need to have some cache of "natural id" -> pk
<EricDalquist> and then we use to pk to load the actual object
<sebersole> well basically what it does (or tries to do) is to handle this cross ref
<sebersole> thats the "looks in the query cache" bit
<sebersole> EricDalquist: exactly what i mean
<EricDalquist> so are you thinking a whole new cache or continuing to essentially overload the query cache?
<sebersole> i'd opt for a whole new cache
<sebersole> using the query cache for this purpose causes problems
<EricDalquist> I would too from an implementers pov, then I can tune it separately from the query cache
<sebersole> that too
<sebersole> like you may or may not want to distribute this cached data
<EricDalquist> right
<sebersole> whereas thats frowned upon for query results
<sebersole> but even more basic, i meant it lets you better handle invalidating the entries
<EricDalquist> yup
* gustavonalle has quit (Quit: gustavonalle)
<EricDalquist> especially if we can just store the base primitives involved in the natural id and pk
<sebersole> you *have* to in fact
<EricDalquist> right, I remember seeing the bug a while back about cache keys having references to assembled objects  :/
<EricDalquist> so the workflow would look like: Lookup pk from NaturalIdCache, On hit load object by PK
<sebersole> yes, you have to dissassemble the values
<EricDalquist> or: Lookup pk from NaturalIdCache, On miss query for pk by naturalid?
<EricDalquist> for that on-miss logic would the code just go through the normal query generation code path?
<sebersole> Lookup correlated pk from NaturalIdCache.  on miss, query db for related key, add to cache.  load by pk
{quote}
  
>  unified approach for id and natural-id loading
> -----------------------------------------------
>
>                 Key: HHH-2896
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896
>             Project: Hibernate Core
>          Issue Type: Improvement
>          Components: core
>            Reporter: Steve Ebersole
>            Assignee: Steve Ebersole
>             Fix For: 3.x
>
>         Attachments: hhh-2896_irc_discussion.txt
>
>
> A follow-on to HHH-2879 in regards to unifying the loading of entities by pk or natural-id.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira