Closed s4ke closed 9 years ago
see TODO in JPASearchFactoryAdapter
maybe it's a good idea then for them to disable the Trigger creation? (this can easily be done by adding a TriggerSource that does nothing).
can we even do native queries for the IdProducerTask of the MassIndexer? this obviously should be submitted by hand. The IdProducerTask could also just be submitted by the user. We can do whatever is better.
People that don't like having any JPA present can always just use a manual-updates backend do manual indexing :). FullTextQuery already has support for EntityProviders.
we need to have the possibility to have EntityProviders which don't need an EntityManager and those that need it.
EntityManagerEntityProviders and normal ReusableEntityProviders should be supported. EntityManagerEntityProviders should use the provided EntityManager (therefore are also wrapped into a transaction). normal ReusableEntityProviders should be used for stuff like JOOQ which don't need any EntityManagers.
EDIT: scrap that. JOOQ has nativeQuery support and all the other libraries should be able to do something similar.
Should we support this for the massindexing as well? I don't think so. Not having managed Objects would mean we need to support fetch profiles. Users can just do that with the already existing EntityManager behaviour in all other classes.
But people can make use of the Adapter class to use the same EntityProvider if they still want to.
if we do this, we can handle the retrieval of the updates in JPA bu NonJPA EntityProviders are possible. Maybe allow a mapping Map Class<?>, EntityProvider>?