[hibernate-dev] natural-id to primary key cache

[Alex Snaps]

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 at 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 at hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
Alex Snaps <alex.snaps at gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps