spring-data-commons icon indicating copy to clipboard operation
spring-data-commons copied to clipboard

MappingContextTypeInformationMapper: No initialization and verification performed on construction [DATACMNS-1627]

Open spring-projects-issues opened this issue 6 years ago • 3 comments

shimikano opened DATACMNS-1627 and commented

While debugging some issues with type aliases, we noticed that MappingContextTypeInformationMapper is not actually initialized with the aliases of the PersistentEntities in the MappingContext given to the constructor:

public MappingContextTypeInformationMapper(MappingContext<? extends PersistentEntity<?, ?>, ?> mappingContext) {
  Assert.notNull(mappingContext, "MappingContext must not be null!");

  this.typeMap = new ConcurrentHashMap<>();
  this.mappingContext = mappingContext;

  for (PersistentEntity<?, ?> entity : mappingContext.getPersistentEntities()) {
    verify(entity.getTypeInformation().getRawTypeInformation(), entity.getTypeAlias());
  }
}

verify(), contradictory to its javadoc, does not modify this.typeMap. Hence, neither verification nor initialization of the map is actually done.

Is this intended or am I missing something?


Affects: 2.2.2 (Moore SR2)

spring-projects-issues avatar Nov 25 '19 16:11 spring-projects-issues

Oliver Drotbohm commented

I skimmed through the file history and it seems that the eager adding was removed in the course of the Java 8 upgrade for 2.0. It shouldn't have any dramatic effect since the actual lookups in createAliasFor(…) still compute aliases lazily.

Do you see any problematic effects of this?

spring-projects-issues avatar Nov 25 '19 20:11 spring-projects-issues

shimikano commented

Thank you for getting back.

I see your point. In case you have persistent entities with conflicting type aliases, as long as both entity types are used as part of a save, createAliasFor(...) gets called both times and the conflict will be caught.

However, we ran into some non-deterministic behavior that held us up quite a bit because we didn't persist both entities in the same run of the application, e.g., after a restart.

In such a case, if a presisted entity is retrieved, in resolveTypeFrom(...), the type may end up depending on the iteration order of entities in the mapping context, which is a HashMap.

Here's a project that demonstrates this: https://github.com/shimikano/DATACMNS-1627

spring-projects-issues avatar Nov 30 '19 20:11 spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

spring-projects-issues avatar Jan 06 '21 10:01 spring-projects-issues