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

[Emmanuel Bernard]

On Thu 2014-02-13 22:27, Gunnar Morling wrote:
> 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.

I am slightly aligned with your view of things. I was also concerned
that once it's used and stored in a datastore, it's for ever as we
should always keep backward deserialization.
But Sanne does feel very strongly about it and my cost benefit algorithm
made me give up :)