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
Likewise, should also provide similar way to configure this in properties/yaml as well.
E.g spring.jpa.entity-scan-classes=com.aa.ClassA,com.aa.ClassB
Comment From: sbrannen
See https://github.com/spring-projects/spring-boot/issues/29193#issuecomment-1005667589 for background information on the proposal.
Comment From: snicoll
If we specify the classes explicitly, it's not really scanning anymore, isn't it? That rather looks like a way to provide the list of entity classes rather than creating the persistence unit manually. That could be interesting with AOT where the regular scanning can happen at build-time.
Comment From: hannah23280
If we specify the classes explicitly, it's not really scanning anymore, isn't it? That rather looks like a way to provide the list of entity classes rather than creating the persistence unit manually. That could be interesting with AOT where the regular scanning can happen at build-time.
Hi, the main purpose for suggesting this, is that sometimes during development, we might want to temporarily turn off scanning all entities except for a few ones, so that our development can concentrate on just a few entities first. E.g I just want to concentrate on entity A, B, C , while the remaining entities might still be unfinished, and might cause errors during boot up, if they are scanned.
To me, scanning list of entity classes is still considered "scan". I use this term "scan" as it align with spring's component scanning feature where it also support scanning by classess.
Comment From: kse-music
This is a bit like the EnableFeignClients annotation, if clients are not provided, use package scanning, otherwise use the provided ones
Comment From: alefq
I agree with the clarification that entities scan should be package scan based.
@hanct , based on your arguments a couple of follow up questions
1. Why would you have unfinished entities on your main or shared branch? I suggest you keep your work in progress (WIP) on a separate unstable branch; before making them available for other developers. You can just comment @Entity
2. A common practice is to use packages for semantic separation, it's customary to keep either all entities under one single package (domain, entities, model, etc. ), possibly with other semantic separations in it (admin, catalog, security, etc.) or to have one of such packages for every module.
Case 1:
admin\
domain\
controller\
service\
catalog\
domain\
controller\
service\
security\
domain\
controller\
service\
Case 2
domain\
admin\
catalog\
security\
controller\
admin\
catalog\
security\
service\
admin\
catalog\
security\
You can come up with your own organization; either way, good practice suggest that your entities should be grouped by package.
Comment From: hannah23280
Hi,
1) Thanks for recommending the good practice of checking into separate unstable working branch. But i believe that to justify for implementing scanning for specific entity classess has nothing much to do with source control management. Sure, we can comment the entity, but sometime this is not necessarily a good option. Point 2, I give an example.
2) Sure, separating them into packages is definitely a good practice, But sometime within the SAME package, we might have 4 out of 5 entities (as an example) that might be configured incorrectly that cause application bootup to throw error. Assuming I have a create user account function in my web app, which consist of 3 pages. First page rely on the the correctly configured entity to be able to display correctly. 2nd page rely on the 3 problematic entities and the last page rely on the remaining 1 problematic entity. As part of the progressive development, it is natural that I want to check and verify that the first page is displayed correctly. Hence one convenient way is to configure the @EntityScan to scan just the 1 entity, so that the application can bootup successfully for me to verify the first page. Thereafter, i can then configure the @Entity Scan to also scan the 3 problematic entities that my 2nd page is relying on. Then i can focus on resolving the 3 problematic entities. Once done, i verify by booting up my application again, and try accessing the 2nd page. I would not be able to boot up my application to verify my 2nd page, if the problematic entity used by the 3rd page is being scanned!!
Perhaps, one might propose why not i resolve the issues for ALL the entities once and for all, before i start verifying the pages. Sure, but at the end, it still boiled down to individual developers preference, and resolving all entities first, before verifying the pages might not always be feasible thing to do . There is no right or wrong. Different developers have their own adapted ways for handling my above-mentioned scenarios.
One might also suggest, why not temporarily move these 4 problematic entities classes out of the scanned package. Sure, that works. But if we have a simpler way of doing things (scanning for specific classes configuration), why not? no one likes to move the entities in and out of the scanned package again and again...
There are definitely valid scenario to justify why we need such feature, that is why online research tells that I am not the only one looking for such feature . In fact, I was also suggesting to be able to exclude scan for specific classess e.g @EntityScan(excludeClassess="MyClass1", so that all classess are scanned except for the listed ones.
Comment From: sbrannen
In fact, I was also suggesting to be able to exclude scan for specific classess e.g
@EntityScan(excludeClasses = "MyClass1"), so that all classes are scanned except for the listed ones.
I'm not convinced that selecting individual entity classes (instead of scanning the package) is worthwhile, but I can foresee it being useful to be able to exclude particular classes based on a filter. That's also what @wilkinsona suggested in https://github.com/spring-projects/spring-boot/issues/29193#issuecomment-1005667589.
Note that @ComponentScan already supports excludeFilters.
Comment From: hannah23280
In fact, I was also suggesting to be able to exclude scan for specific classess e.g
@EntityScan(excludeClasses = "MyClass1"), so that all classes are scanned except for the listed ones.I'm not convinced that selecting individual entity classes (instead of scanning the package) is worthwhile, but I can foresee it being useful to be able to exclude particular classes based on a filter. That's also what @wilkinsona suggested in https://github.com/spring-projects/spring-boot/issues/29193#issuecomment-1005667589.
Note that
@ComponentScanalready supportsexcludeFilters.
I support the idea of exclude based on filter, as it is more flexible.
Comment From: hannah23280
In fact, I was also suggesting to be able to exclude scan for specific classess e.g
@EntityScan(excludeClasses = "MyClass1"), so that all classes are scanned except for the listed ones.I'm not convinced that selecting individual entity classes (instead of scanning the package) is worthwhile, but I can foresee it being useful to be able to exclude particular classes based on a filter. That's also what @wilkinsona suggested in spring-projects/spring-boot#29193 (comment).
Note that
@ComponentScanalready supportsexcludeFilters.
Even though i support the idea of exclude on filter, but why not make it more complete by also giving the ability to include only specific ones. To cater for a wide range of developers.
Comment From: snicoll
We have a prototype ready to be investigated by the Spring Boot team and we can then merge accordingly.