Skip to content

Conversation

@mp911de
Copy link
Member

@mp911de mp911de commented Nov 3, 2017

We now check for registered simple types in MongoMappingContext.shouldCreatePersistentEntityFor(…) to prevent PersistentEntity creation for unwanted types. Previously, we only checked against MongoSimpleTypes.HOLDER instead of the simple types contributed by converters.

This change impacts aggregate root type use with top-level converters: These types are no longer represented with a PersistentEntity which removes mapping details and these types cannot be used anymore with a repository and require a collection name if used with the Template API.


Related ticket: DATAMONGO-1819.

@odrotbohm
Copy link
Member

Do you have details on the side-effect?Should we maybe move the JSR-310 converters more closely to the default converters so that would've been caught by the previous implementation of shouldCreatePersistentEntityFor(…)?

@mp911de
Copy link
Member Author

mp911de commented Nov 3, 2017

Consider following code:

@Document("another_collection") class Person { … } class PersonWriteConverter implements Converter<Person, Document> { … } class PersonReadConverter implements Converter<Document, Person> { … }

Then you're required to call MongoTemplate.findAll(Person.class, "another_collection") instead of MongoTemplate.findAll(Person.class) (The latter one works because of the bug).

Creating a repository interface PersonRepository extends Repository<Person, String> fails with:

org.springframework.data.mapping.MappingException: Couldn't find PersistentEntity for type class com.acme.Person!	at org.springframework.data.mapping.context.MappingContext.getRequiredPersistentEntity(MappingContext.java:76)	at org.springframework.data.mongodb.repository.support.MongoRepositoryFactory.getEntityInformation(MongoRepositoryFactory.java:149)	at org.springframework.data.mongodb.repository.support.MongoRepositoryFactory.getTargetRepository(MongoRepositoryFactory.java:123)	at org.springframework.data.repository.core.support.RepositoryFactorySupport.getRepository(RepositoryFactorySupport.java:298)	at org.springframework.data.repository.core.support.RepositoryFactorySupport.getRepository(RepositoryFactorySupport.java:259) 

Moving JSR310 support back to MongoSimpleTypes in would fix this particular issue but that's just a patch, not fixing the actual issue. Another possibility to catch more of the unwanted types could be performing the converter-based simple type check on java.* and org.bson.* packages.

@mp911de mp911de force-pushed the issue/DATAMONGO-1819b branch from e171096 to a2186a5 Compare November 3, 2017 16:01
We now check during query mapping whether a property represents a simple value or an entity to not request a PersistentEntity if not required. Previously, we relied entirely on the MappingContext to return a PersistentEntity which could also happen for types that were simple types. Fix id property name in DefaultScriptOperations as we provide a converter for NamedMongoScript.
Migrate tests to AssertJ.
@mp911de mp911de force-pushed the issue/DATAMONGO-1819b branch from a2186a5 to fa0c3fd Compare November 6, 2017 07:15

MongoPersistentProperty property = getProperty();
return property == null ? null : mappingContext.getPersistentEntity(property);
return property != null && property.isEntity() ? mappingContext.getPersistentEntity(property) : null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should rather make the ….isEntity() check part of the implementation of getPersistentEntity(PersistentProperty). That would prevent that any other calls to that method with a property that's not an entity in the first place would trigger the addition of the type to the mapping context and the code here could even stay untouched.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing either one is rather a patch than a fix to the actual issue. There's no coherent behavior between PersistentProperty.isEntity() and AbstractMappingContext.shouldCreatePersistentEntityFor(…) as both run different checks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally agree, however, I'd argue it sort of has to be that way (to support the use case you described above). What I am trying to say is, on getPersistentEntity(PersistentProperty), we know that we're in the "nested" case, so that stricter rules might apply and actually can be applied. I.e. in case of the lookup of the PersistentEntity for a PersistentProperty we can apply more strict rules before adding a previously not-known type to the MappingContext than when asking for a PersistentEntity on the MappingContext as that implicitly assumes top-level types to some degree.

I'd also it's inline with the previously implicit assumption that looking up a PersistentEntity for a property, that the latter actually is considered one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right about the relationship between a property and its reference to a top-level type. We generally want to avoid introspection of types that are considered simple ones.

Let's do it that way. I'll file a separate ticket to address the missing simple type check in shouldCreatePersistentEntityFor(…).

mp911de added a commit that referenced this pull request Nov 17, 2017
Use native field names for NamedMongoScript query instead of relying on metadata-based mapping as NamedMongoScript is considered a simple top-level type. Migrate tests to AssertJ. Related pull request: #513.
mp911de added a commit that referenced this pull request Nov 17, 2017
Use native field names for NamedMongoScript query instead of relying on metadata-based mapping as NamedMongoScript is considered a simple top-level type. Related pull request: #513.
@mp911de mp911de closed this Dec 15, 2017
@mp911de mp911de deleted the issue/DATAMONGO-1819b branch December 15, 2017 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants