"NullPointerException" when indexing no indexable entity
If an unindexed entity is found in the indexed list, indexing ends with an exception.
After deleting the fragment, I have the message:
Error readability better than "NullPointerException". So deleting this fragment solves the problem.
The test "MassIndexingComplexHierarchyIT #rootIndexed_someSubclassesIndexed_requestMassIndexingOnRoot" checks for correctness. However, the test will run correctly after removing this fragment. The "JavaBeanIndexingStrategies" checks the validity of the indexed entities so the defective fragment can be removed.
You mean you want to send a PR to remove this snippet of code? I’m definitely in favor, yes. It shouldn’t be there, since it’s the user’s responsibility to return (only) entities of the type Hibernate Search asked for.
Can it just remove the entity filtering fragment?
When you don't filter unindexed entities, this will still be caught and an appropriate exception will be thrown. Then the developer will watch the correctness of the returned entities.
Come to think of it, the fact that this code even exists in PojoMassIndexingTypeProcessor.java is, in my opinion, a mistake:
The core principle behind the identifier scroll and loader is that we only load entities that are included in a given type group. That’s why in the ORM implementation we have a Set<? extends Class<? extends E>> includedTypesFilter parameter in methods of org.hibernate.search.mapper.orm.loading.impl.TypeQueryFactory: if what Hibernate Search wants is not all the subtypes of a given parent type, then we need to filter entities by type. See org.hibernate.search.mapper.orm.loading.impl.AbstractHibernateOrmLoadingStrategy#createQueryLoader in particular.
If your custom loader cannot do that, then you will end up loading many more entities than necessary, and performance will suffer. So we need to get to the bottom of this, rather than adding some bandaid by having Hibernate Search filter after loading.
Why is it you cannot filter before loading?