Configure the auto-configured LocalContainerEntityManagerFactoryBean with any ManagedClassNameFilter beans

[hannah23280]

Hi,

I would like to request for @EntityScan to be able to provide the ability to scan for specific entities class, rather than based on package. E.g @EntityScan(classes={"com.aa.ClassA", "com.aa.ClassB")) will only scan for these 2 classes and other classes in the same package will NOT be scan.
Searching internet shows many people asking for such capabilities and end up having to write some codes to circumvent this.
Adding such capabilities made life easy for developers

[hannah23280]

Hi,

I would like to request for @EntityScan to be able to provide the ability to scan for specific entities class, rather than based on package. E.g @EntityScan(classes={"com.aa.ClassA", "com.aa.ClassB")) will only scan for these 2 classes and other classes in the same package will NOT be scan. Searching internet shows many people asking for such capabilities and end up having to write some codes to circumvent this. Adding such capabilities made life easy for developers

In addition, should also provide similar way to configure this in properties/yaml as well.
spring.jpa.entity-scan-classes=com.aa.ClassA,com.aa.ClassB

[wilkinsona]

Thanks for the suggestion. Entity scanning is heavily package-based at the moment, particularly for JPA where Spring Framework's LocalContainerEntityManagerFactoryBean and DefaultPersistentUnitManager is used. As such, for Spring Boot to be able to offer more control over the entities that are found by scanning, we'd need some changes in Spring Framework. If this is something that you'd like to pursue, please open a Spring Framework issue. If the Framework team add filtering support or similar we can then revisit this issue and consider exposing that new capability via @EntityScan.

In the meantime, assuming that you're using JPA, you may be able to achieve a custom property-based solution by providing your own PersistentUnitManager implementation.

[wilkinsona]

@snicoll has prototyped something for this. We should take a look at it and see what we could now do with @EntityScan.

[wilkinsona]

Looking at the change in Framework, it occurs to me that hooking this into @EntityScan won't be straightforward as the Framework change is (quite reasonably) JPA-specific while @EntityScan applies to several different persistence technologies and we'd have to apply any filtering implied by @EntityScan consistently across all of the different stores. On an initial inspection, that looks to be possible, but it broadens the scope of the changes quite a bit.

For many (all?) of the non-JPA stores, scanning for specific classes is already possible by providing a …ManagedTypes bean such as CassandraManagedTypes, MongoManagedTypes, or Neo4jManagedTypes. There is no support for property-based filtering. Interestingly, these stores deal with Class instances for their managed types whereas String instances are used on the JPA side. This further complicates things as the different types affect the ways in which more complex filtering may be performed.

Taking a small step back, I am not sure that @EntityScan is the right way to provide this functionality. It feels like annotation attributes may be quite limiting in terms of more sophisticated filtering where classes may be included or excluded. Furthermore, sophisticated class-based filtering is already possible for non-JPA stores and introducing something at the @EntityScan level would have to be String-based and, therefore, less capable.

I think the best route forward here may be to provide a JPA-specific filtering interface and for Boot to set such filters on the auto-configured LocalContainerEntityManagerFactoryBean, probably through some changes to EntityManagerFactoryBuilder. This would be easier and require one less layer if Framework's API used a specific interface for the filter rather than Predicate<String>. Is that an option, @snicoll?

[snicoll]

Yes! Juergen and I brainstormed and he's suggesting ManagedClassNameFilter.

[philwebb]

Closing in favor of PR #39813. Thanks @quaff!