DATACMNS-447 - Soften too strict check in MappingContext if no PersistentEntity type. #71
Conversation
…trict checking and shouldCreatePersistentEntity is wrong.
|
I don't quite like the extraction of the protected methods as it exposes internals to subclasses that could be achieved by using the existing hooks (implementations of I am not totally against refactoring the code to provide more hooks, it's just that it seems to happen here without any context and justification. |
|
The protected methods come from Michaels initial commit and I thought it is useful to have this hooks to be able to provide more sophisticated customizations. I can make those methods private if you prefer - then we could probably inline publishMappingContextEvent and verifyEntity. @jexp Could we make those methods private or do you need those for further MappingContext customizations in SD Neo4J? |
|
I actually do more customization. |
|
I suggest to to open a new ticket to provide more context about the intended changes and proceed with just the strict-checks fixed for this PR. |
|
I reduced this PR to only contain the changed ordering of the checks in AbstractMappingContext.getPersistentEntity(TypeInformation). I created https://jira.springsource.org/browse/DATACMNS-459 to track the refactoring efforts. |
…tentEntity type. Previously we directly threw a MappingException in MappingContext.getPersistentEntity(TypeInformation) when the MappingContext was in strict mode and we were given a TypeInformation for which we didn't have a PersistentEntity already. We now first check whether we should actually create a PersistentEntity for the given TypeInformation if no PersistentEntity is available, before throwing a MappingException - if we should not then we simply return null (e.g. for simple types like Integer or Double). Original pull request #66.
|
@jexp - Would you mind elaborating in DATACMNS-459 on why you think the changes where necessary? |
Previously we directly threw a MappingException in MappingContext.getPersistentEntity(TypeInformation) when the MappingContext was in strict mode and we were given a TypeInformation for which we didn't have a PersistentEntity already. We now first check whether we should actually create a PersistentEntity for the given TypeInformation if no PersistentEntity is available, before throwing a MappingException - if we should not then we simply return null (e.g. for simple types like Integer or Double). Original pull requests: #66, #71.
Previously we directly threw a MappingException in MappingContext.getPersistentEntity(TypeInformation) when the MappingContext was in strict mode and we were given a TypeInformation for which we didn't have a PersistentEntity already. We now first check whether we should actually create a PersistentEntity for the given TypeInformation if no PersistentEntity is available, before throwing a MappingException - if we should not then we simply return null (e.g. for simple types like Integer or Double). Original pull requests: #66, #71.
Previously we directly threw a MappingException in MappingContext.getPersistentEntity(TypeInformation) when the MappingContext was in strict mode and we were given a TypeInformation for which we didn't have a PersistentEntity already. We now first check whether we should actually create a PersistentEntity for the given TypeInformation if no PersistentEntity is available, before throwing a MappingException - if we should not then we simply return null (e.g. for simple types like Integer or Double). Original pull requests: #66, #71.
Previously we directly threw a MappingException in MappingContext.getPersistentEntity(TypeInformation) when the MappingContext was in strict mode and we were given a TypeInformation for which we didn't have a PersistentEntity already.
We now first check whether we should actually create a PersistentEntity for the given TypeInformation if no PersistentEntity is available, before throwing a MappingException - if we should not then we simply return null (e.g. for simple types like Integer or Double).
Opened-up API for customization in sub-classes.
Original pull request #66.