-
Notifications
You must be signed in to change notification settings - Fork 22
Description
Currently, our generic CaseClassTypeInfo
and CaseClassSerializer
don't handle recursive case classes. This issue is created from PR discussions in #280.
I was able to hack something in LowPrioImplicits
thanks to the cache of TI: the idea is to store an incomplete temporary TI without field serializers initialized to break the recursivity, and do the field serializers initialization only once, after: it finds temporary TI in the cache so it doesn't try to initialize it another time, effectively breaking the recursivity.
If we want to handle recursivity in CaseClassSerializer
we have to do something similar with a global cache for all recursively processed fields (at least getLength
, isImmutableType
, isImmutableSerializer
, createInstance
, equals
, hashCode
and maybe the most tricky one snapshotConfiguration
) and find a coherent short-circuit for each (what is the length of a recursive serializer? In theory, its length is infinite, in practice it can be -1
).
Similar problems occur also on CaseClassTypeInfo
and its parent TupleTypeInfoBase
: getFlatFields
, getTypeAt
, getTotalFields
, equals
, hashCode
and toString
.
Maybe memoization or dynamic programming can help to solve these problems: https://stackoverflow.com/a/6185005/6176274