On Thu 2014-02-13 22:27, Gunnar Morling wrote: > 2014/2/13 Emmanuel Bernard <emman...@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 :) _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
