Re: [hibernate-dev] natural-id to primary key cache
This has been a recurring subject in the ehcache forum and a source of
misunderstanding by many.
Having the second level cache support these as "first class citizen"
makes total sense to me. Is there some draft of how this would look
like ? Would this be a mapping of natural id to primary key ?
Sorry for not replying any earlier, but I totally oversaw this. Also,
I might be asking the obvious here. Will start looking around the
Loader for natural ids in the meantime.
Do you guys think we can still sync to have the new API in both
Infinispan & Ehcache, or is time running short ?
On Fri, Jan 20, 2012 at 1:20 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
Historically natural-id look ups were accomplished by leveraging
Criteria queries. Caching was handled through the second level query
cache.
One of the new things in 4.1 is the dedicated natural-id loading API.
So the caching will be quite different here. I am a little leery about
making a breaking changes in 4.1 after all the changes in 4.0 if we can
avoid it. If we can't we can't. One thought for this was to use a
SessionFactory scoped "cache" for this in 4.1 and then add a new second
level cache Region construct for this in 5.0. The *only* benefit is to
keep the second level cache SPI the same between 4.0 and 4.1. Is that
worth it? Any thoughts?
--
steve(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps