I really dislike the idea of having a mutable key,
am I too extreme? isn't this going to bring you loads of problems?
IMHO if it's mutable it is not a key, but of course I don't see the big picture:
I'm just curious about the design decision.
kind regards,
Sanne
2008/9/16 Elias Ross <[EMAIL PROTECTED]>:
> I've been looking to optimize the caching of an application which uses
> a mutable natural key, an account phone number.
>
> Hibernate does not yet support optimized caching of
> @NaturalId(mutable=false), because of how the current natural ID
> relies on immutable IDs. The caching associates a QueryKey -> results
> and it's impossible to evict the QueryKey since the natural keys are
> embedded in it.
>
> One solution I considered was to create an association between a set
> of natural ID values and "QueryKey". When a query is made with mutable
> natural keys, an association would be made. This could be done within
> "StandardQueryCache." And then when an entity is updated or removed,
> if there are mutable natural keys, Hibernate could locate the query
> and remove it as well. I'm not sure how I could implement this part.
> I'm guessing I'd have to add a method to QueryCache to do the removal.
>
> public interface QueryCache {
>
> ...
> public void remove(NaturalIdAssocation nia) throws HibernateException;
>
> }
>
> public class NaturalIdAssociation implements Serializeable {
> Type type;
> Set<Object> keys;
> }
>
> Actually, thinking this over, having this removal operation would fix
> some other issues when non-mutable natural id entities are removed.
> For instance, HHH-3478, a problem found using EntityManager and
> natural IDs.
>
> Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
