Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Reference deduplication does not apply to polymorphic references

Abierto
#4,331 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
java, mongodb
Área
database

Línea de trabajo

Start by tracing registration in EntityDecoder and lookup in ReferenceCodec through DecodeSession, then inspect how DecoderContext could carry the source collection or how a mapped root type could identify the entity. Choose and document a design that avoids false hits; done means polymorphic @Reference values reuse the in-flight entity instead of issuing a duplicate database lookup.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Reference deduplication (DecodeSession, added on the resume-reference-caching work) silently does nothing for references whose declared type is a supertype of the stored document's actual type.

Why

EntityDecoder registers a decoded entity under the concrete model's collection:

session.registerInFlight(classModel.collectionName(), prereadId, ...);

After discriminator resolution classModel is the subtype's model, so a Child document registers under child. ReferenceCodec looks the entity up under the declared type's collection:

String collection = id instanceof DBRef
        ? ((DBRef) id).getCollectionName()
        : entityModel.collectionName();

For @Reference Base ref that is base. The keys never match, so every such reference misses the cache and goes to the database.

When the subtype has no explicit @Entity value the two names differ because EntityModel.getCollectionName() falls back to the naming strategy over the simple class name — Base -> base, Child -> child.

Impact

Correctness is unaffected: a miss just falls through to the existing query path and returns a correct (if duplicated) instance. The only cost is that deduplication and the cross-document instance sharing it provides are quietly absent for polymorphic references, which is surprising given the feature is documented as applying to @Reference generally.

Why it was not fixed with the rest

The decoder does not know which collection the document was actually read from, only which model it is decoding into. Fixing it properly means either threading the source collection into the decode, or registering an entity under every collection name in its type hierarchy — the latter risks false hits where unrelated types share a derived name, so it wants a deliberate design decision rather than a quick patch.

Suggested approaches
  • Thread the source collection name through DecoderContext (or an equivalent) so registration keys on where the document actually lives.
  • Or key the session on the entity's mapped root type rather than a collection name, which sidesteps the naming mismatch entirely.
Lenguaje dominante
Java
Estrellas
1.7k
Forks
449
Merge medio
13 h 56 min
PR fusionados (30 d)
62

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MorphiaOrg/morphia

Todos los issues de MorphiaOrg/morphia

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.