Description
Daniel Schweighöfer opened DATACMNS-1330 and commented
For a SpringBoot project, the org.springframework.data.repository.support.DomainClassConverter is registered to automatically convert Entities into their IDs or IDs into their respective Entities via the Repository system. This converter is registered as Object -> Object. When searching for a appropriate converter while binding data to a form, this means, that this converter is checked last, after any more specific converter.
Unfortunately, there is the org.springframework.core.convert.support.FallbackObject converter which is registered in the ConversionService as Object --> String. Now in the very specific case it is possible that this fallback converter is valid for a @Entity -> String conversion, which causes this converter to be used instead of the DomainClassConverter.ToIdConverter. On the surface, this provides a seemingly inexplainable conversion of nearly identical @Entity classes to different String representations, even when BOTH classes have a toString method implemented (which turns out not to be relevant).
The case in which the FallbackToStringConverter is matched is triggered, when the entity is seemingly convertable FROM a string. That is when the method inspection on the class finds a Constructor taking exactly one string or a static function which turns a string into an instance.
In my case, an @Entity which had just a generated primary key and a string name triggered this behavior, as I created a constructor which only set the name, expecting the ID to be generated upon persisting. The expected behavior would have been that the DomainClassConverter is registered with the conversion service for every entity --> Object and ID --> Entity separately, which would make it take precedence over the FALLBACK solution implemented for all conversions with strings
No further details from DATACMNS-1330