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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896?page=c... ] 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} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira