Using @EntityScan lets Spring Boot scan all entities within one or more base packages to supply the discovered types to various Spring Data MappingContexts.

Initial entities in MappingContext can lead to various actions on component initialization (application startup) and there's currently no possibility to exclude entity types through filters. A common workaround is placing entities outside of the base packages that may or may not work, depending on the package structure.

It would be nice to have include/exclude filters (similar to @ComponentScan) for a fine-grained control of scanning.

Comment From: philwebb

Unfortunately we're going to need quite a few upstream changes to support this. We've got LocalContainerEntityManagerFactoryBean for JPA, SessionFactory for Neo4J and CassandraEntityClassScanner for Cassandra.

@mp911de What would be some good examples where you want to filter an entity?

Comment From: mp911de

Examples in which you want to be more selective about initial/scanned entities are:

  • Distinguish which entities are loaded during startup.
  • For Cassandra: Manage schema for a subset of entities (Spring Data Cassandra can create/drop schema based on entity definitions).
  • For stores using database routing (e.g. MongoDB): Initial entities allow upfront collection/index creation (when creating MongoTemplate), collections/indexes should be created on access routed to the appropriate database.

Comment From: atealxt

Provide another use case:

A spring boot fat jar contains two entities with same class name (& table) but different package. One is from BOOT-INF/classes! (A), the other is from /BOOT-INF/lib/XXX.jar (B). During start, hibernate InFlightMetadataCollectorImpl revealed A is overridden by B.

The use case is when you actually need A, without change class name/package, or class load order.

Comment From: brindhats

is this issue addressed? Distinguish which entities are loaded during startup.

Comment From: wilkinsona

@brindhats No, this issue is open and has not yet been addressed.

Comment From: denniseffing

Providing another use case:

Spring Statemachine offers persisting the state machine configuration and persisting the state machine itself. We only want to persist the state machine itself (not its configuration) because the configuration is static anyways.

The Spring Statemachine autoconfiguration loads all entities at the same time (the entities needed to persist the configuration and the entities needed to persist the state machine itself). Our Hibernate ddl-auto setting is set to validate and now expects several tables to exist (even those we don't want to use!).

We tried replacing the autoconfiguration, to configure the entity scan ourselves but then noticed that all entities share the same package. We can't change the package structure of the Spring Statemachine library (except by providing a PR maybe) and are now facing this issue.

Comment From: mikelhamer

Another use case:

I'm using Flyway with strict schema validation on, and want to keep my app in a deployable state at all times. When working with a new @Entity during development, I want to only have that entity registered when the dev profile is active, or perhaps don't register entities that contain a custom annotation such as @DevOnly. This way I can always safely deploy to prod, even if @Entity classes exist that don't have a corresponding schema in the database yet. I don't want to have to turn off strict migration