[hibernate-dev] [OGM] When is AssociationKey serialized?

Gunnar Morling gunnar at hibernate.org
Thu Feb 13 16:27:01 EST 2014


2014/2/13 Emmanuel Bernard <emmanuel at hibernate.org>

> > >> The thing is only the key/value dialects do make use of the keys
> objects.
> > >> And even in that case, it might not make sense to actually reuse these
> > >> objects. For example if the cache name is the table and only the id
> columns
> > >> are part of the key.
> > >> Is that edge case worth this complexity (interfaces and splitting the
> > >> metadata)? Maybe with optional methods in the grid dialect? That
> would still
> > >> make me sad I guess :)
> >
> > Actually these keys where originally designed to be the keys in
> > key/value stores and the cost of not reusing them is high, so I'm not
> > following why you would like to make them not Serializable; indeed
> > some have some fields which need to be moved out, but there are JIRA's
> > open for that already as it's an important consideration for storage
> > size -> memory consumption: OGM-151
> >
> > I'm not sure I understood what you are suggesting we could do when the
> > "cache name is the table and only the id columns are part of the key":
> > to use just the array for the key? Sadly we need to override equals of
> > the array, so at least one wrapper is needed (unless we find a way to
> > override comparisons in Infinispan and all others). But a second
> > wrapper is simply "one too much" because conceptually we don't need
> > it.
>
> Sanne and I took the conversation online and we could only agree that
> the other one was crazy.
> But we also agree that making AssociationMetadata Serializable was
> cheap.


So to be sure, you mean these keys *should* be serializable and stores
should be allowed to use them as is as the persistent representation?


> Hopefully we won't regret that contract enhancement.
>

To me it seems a bit like premature optimization. There is one known case
which actually benefits from this and we don't really know the penalty for
creating the wrapper in this case. In most stores we need to create another
representation anyways (e.g. DBObject for MongoDB). But once used as
Serializable in the wild, we can't get back out of this and must be very
careful or may be limited when evolving these types.

--Gunnar

PS: Does anyone know what has happened to
https://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/?
I'm getting a 404 there.



>
> Emmanuel
>


More information about the hibernate-dev mailing list