Call to save(…) on customized intermediate repository fails with "Object is not an instance of declaring class." [DATACMNS-1289]

[spring-projects-issues]

Markus Demetz opened DATACMNS-1289 and commented

When using custom implementations of Spring Data repositories together with inheritance and inherited entities (single table inheritance), I get a
InvalidDataAccessApiUsageException: object is not an instance of declaring class;
after upgrading Spring Boot from 1.5.10 to 2.0.0.

Example attached

---

Affects: 2.0.6 (Kay SR6)

Attachments:

• bug-inheritance.zip (16.00 kB)
• inheritance-working.zip (16.81 kB)

Referenced from: pull request #280

Backported to: 2.0.7 (Kay SR7)

[spring-projects-issues]

Jens Schauder commented

The custom implementations need to be named after the custom interface they provide implementations for.

So if you rename XDaoImpl into XDaoCustomImpl it works

[spring-projects-issues]

Jens Schauder commented

@ Mark Could you take a look at this?

It seems to consider the custom implementation to belong to the full repository interface implementation and then checks the presence of a method by looking at the interface instead of the implementation class.

This results in the custom implementation being used for save although it doesn't have a save method.
Not sure if this is just a case of bad error message or if there is actually a bug hiding behind this

[spring-projects-issues]

Mark Paluch commented

We're attempting to call save(…) on ComponentDaoImpl because we consider ComponentDaoImpl a repository implementation as it matches the naming pattern between its interface ComponentDao and ComponentDaoImpl.

The catch here is that ComponentDaoImpl does not implement CrudRepository methods (inherited from CustomDao via JpaRepository). Basically what Jens Schauder said before.

Annotating ComponentDao with @NoRepositoryBean excludes the intermediate repository.

I think we could improve on repository fragments by checking whether the implementation actually provides the method to come up with a better exception message

[spring-projects-issues]

Markus Demetz commented

Actually I wanted to be able also to query against Component s for common properties via ComponentDao<Component> dao and keeping the inheritance structure mirroring the domain model. Putting a NoRepositoryBean would break this possibility.
Renaming XDaoImpl into XDaoCustomImpl works.

Regarding the namings:
I use

• ComponentDao for generated interfaces from a generator,
• ComponentCustomDao for hand-written interfaces, and
• Component[Custom]DaoImpl for its implementation.

All of these for every inheritance layer.
For Component[Custom]DaoImpl I just wanted to avoid unneccessarly long class names, since the Impl suffix in this case already suggests a customized implementation.

Another working solution [^inheritance-working.zip] would be to rename ComponentDao into e.g. AbstractComponentDao, put a @NoRepositoryBean onto it and create a new interface ComponentDao extends AbstractComponentDao<Component>.

[spring-projects-issues]

Mark Paluch commented

I moved this one to Spring Data Commons since all fragment-related functionality lives in commons

[spring-projects-issues]

Mark Paluch commented

For now, we'll improve the error message to indicate the type/implementation mismatch. In a second step, it could be interesting to allow customization of intermediate repository interfaces by filtering methods inherited from @NoRepositoryBean interfaces