>> 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. Hopefully we won't regret that contract enhancement.
Emmanuel