Unable to disambiguate inherited fields in fhir-model

[eboozer]

Describe the bug
I am currently attempting to use the fhir-model using the Spring-boot framework with MongoDB. Unfortunately, there is a convention used in each of the resource classes that is preventing me from creating the MongoDB document. It looks like each resource creates its own private hashCode field that is used for the hashCode method. Unfortunately, when spring-boot attempts to convert these resources into a document type, it is unable to "disambiguate" the fields between the child and parent classes. This appears to be an issue with all of the Resource objects, so the included below call stack only includes the "first" conflict Spring-boot runs across.

The call stack is rather tall, but here is the relevant portion:

Caused by: org.springframework.data.mapping.MappingException: Ambiguous field mapping detected! Both private volatile int com.ibm.fhir.model.type.String.hashCode and private volatile int com.ibm.fhir.model.type.Id.hashCode map to the same field name hashCode! Disambiguate using @Field annotation!
	at org.springframework.data.mongodb.core.mapping.BasicMongoPersistentEntity$AssertFieldNameUniquenessHandler.assertUniqueness(BasicMongoPersistentEntity.java:355) ~[spring-data-mongodb-3.1.8.jar:3.1.8]
	at org.springframework.data.mongodb.core.mapping.BasicMongoPersistentEntity$AssertFieldNameUniquenessHandler.doWithPersistentProperty(BasicMongoPersistentEntity.java:341) ~[spring-data-mongodb-3.1.8.jar:3.1.8]
	at org.springframework.data.mongodb.core.mapping.BasicMongoPersistentEntity$AssertFieldNameUniquenessHandler.doWithPersistentProperty(BasicMongoPersistentEntity.java:335) ~[spring-data-mongodb-3.1.8.jar:3.1.8]
	at org.springframework.data.mapping.model.BasicPersistentEntity.doWithProperties(BasicPersistentEntity.java:360) ~[spring-data-commons-2.4.8.jar:2.4.8]
	at org.springframework.data.mongodb.core.mapping.BasicMongoPersistentEntity.verifyFieldUniqueness(BasicMongoPersistentEntity.java:218) ~[spring-data-mongodb-3.1.8.jar:3.1.8]
	at org.springframework.data.mongodb.core.mapping.BasicMongoPersistentEntity.verify(BasicMongoPersistentEntity.java:201) ~[spring-data-mongodb-3.1.8.jar:3.1.8]
	at org.springframework.data.mapping.context.AbstractMappingContext.addPersistentEntity(AbstractMappingContext.java:387) ~[spring-data-commons-2.4.8.jar:2.4.8]

Since this is a 3rd party jar, the proposed resolution in the stack is impossible to do (without some amount of hackery and bad practices), and wouldn't make sense to implement it for everyone that consumes the jar. However, I believe a better completely passive fix for this would be to simply change the hashCode to protected instead of private for the root elements, and remove the field for all of the child classes. This would allow access for each resource type without the conflict, and should be 100% passive with the functionality. It would be a bit tedious to change each of the resources, but I'm willing to make the change if we agree this is an issue.

Environment

• fhir-model-4.8.0
• spring-boot-2.4.5
• java-11/kotlin-1.5.0

To Reproduce
Steps to reproduce the behavior:

1. Create Spring-boot MongoDB project that can ready/write documents to MongoDB
2. Include fhir-model in project
3. Create a document that corresponds to any resource object that has a private hashCode field and extends other object that also has a hashCode field
4. Start your Sprint-boot project and attempt to read/write the document to the DB. Spring-boot will trigger the error based on its own reflection introspection analysis

Expected behavior
A fhir-model Resource type should be able to be saved to a Spring-boot MongoDB without issue

[lmsurpre]

its a private member so should be safe for us to change. let me give it a go quick and maybe you can help confirm that its as simple as I think it is...

[lmsurpre]

@eboozer these changes were shipped in IBM FHIR Server 4.8.1 ...mind trying with that or 4.8.2 and confirming that it addresses the issue you were seeing? If we don't hear back in a day or two, we'll plan to close the issue.

[eboozer]

That's awesome! Thank you for following up. I was able to figure out a temporary workaround/hack to bypass the issue. But I should be able to revert that change in the next couple of days to confirm. I will follow-up as soon as I know.

[lmsurpre]

Marking this closed...please reopen if you find it not working as expected.

[eboozer]

Yes, I was able to confirm that this corrected my issue. Thank you for the quick turnaround.