When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code:

List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList();

The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names.

This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene).
Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database.

This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as:

private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) {
if (customLoader!=null) {
customLoader.init(session, sessionFactoryImplementor);
return customLoader;
}
...
}

After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list".

There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications.