We have the use case that we’re storing deeply nested objects in MongoDB. Certain fields in this object can have different types. For instance let’s say an object can have a field that’s a collection of InterfaceType and there are different implementations of that say: ConcreteTypeA, ConcreteTypeB with different fields.
package foo.bar
sealed interface InterfaceType
data class ConcreteTypeA(val aField1: String, val aField2: Int) : InterfaceType
data class ConcreteTypeB(val bField: List<String>) : InterfaceType
When using Spring Data Mongo DB to persist say:
package bar.foo
@Document("myCollection")
data class MyDocument(
@Id id: String,
val value: InterfaceType
)
Spring will automatically add fields called `_class`` that helps to instantiate the correct class on read. See also: Type Mapping :: Spring Data MongoDB
{
"value" : {
"aField1" : "some value",
"aField2" : 1234,
"_class" : "foo.bar.ConcreteTypeA"
},
"_class" : "bar.foo.MyDocument"
}
This all works fine, but of course this is not very refactoring safe… renaming the class or moving it to a different package will fail when reading the document. We could use @TypeAlias and register the aliased classes in the config, that would allow renaming/moving the class. Or alternatively have Document classes with lots of nullable fields and handle everything in the Repository.
What’s the recommended approach to handle this type of data structure in Spring?