Voici donc l'histoire :nous ajoutons le type par défaut comme une sorte d'indice sur la classe à instancier réellement. Comme vous devez diriger un type pour lire le document via MongoTemplate de toute façon il y a deux options possibles :
- Vous remettez un type auquel le type stocké réel peut être assigné. Dans ce cas, nous considérons le type stocké, utilisez-le pour la création d'objets. L'exemple classique ici est de faire des requêtes polymorphes. Supposons que vous ayez une classe abstraite
Contactet votrePerson. Vous pouvez ensuite interrogerContacts et nous devons essentiellement déterminer un type à instancier. - Si vous - d'un autre côté - transmettez un type complètement différent, nous nous contenterons de le regrouper dans ce type donné, pas dans celui stocké dans le document en fait. Cela couvrirait votre question sur ce qui se passe si vous déplacez le type.
Vous pourriez être intéressé à regarder ce ticket qui couvre une sorte de stratégie de mappage de type enfichable pour transformer les informations de type en un type réel. Cela peut simplement servir à des fins d'économie d'espace, car vous souhaiterez peut-être réduire un long nom de classe qualifié à un hachage de quelques lettres. Cela permettrait également des scénarios de migration plus complexes dans lesquels vous pourriez trouver des clés de type complètement arbitraires produites par un autre client de magasin de données et les lier à des types Java.
