Recently I've done huge migration from hibernate-search-3.0.0.GA to hibernate-search-orm-5.6.1.Final. In our project we have a lot of @Indexed entities and quite sophisticated hierarchy. There's abstract @Indexed @MappedSuperclass which has @Indexed subclasses. Simplifying thing it could be written like following:
I found it very interesting, that after switch all the entities started to be populated in the index for class (we're using FSDirectoryProvider as a provider) A, even though I'm trying to index B instances. Quick analysis shows, that during creation of IndexManagerGroupHolder there's wrong name passed as first argument for org.hibernate.search.indexes.impl.IndexManagerHolder#getOrCreateGroupHolder. Following that further one could see, that in org.hibernate.search.indexes.impl.IndexManagerHolder#getIndexName there appears to be index name evaluation:
which then followed by return statement:
If I do get comment before the loop right, this method should return the most specific index name either from @Index.name or fully-qualified class name of the @Indexed entity.
Question is is my understanding correct? If so that in my case, when indexing subclass B I should get as an index name fully qualified name of class B. Problem is, that I get fqcn of A instead.
Problem appears to be serious, when one's using exclusive_index_use=true, which is default now.
Hi , thanks for a quick response!
What I was implying on, talking about exclusive_index_use, that we have multiple JVMs which share the same FS index, and thus we have a lot of org.apache.lucene.store.LockObtainFailedException, which causes indexing batches to fail. Though that the other story
With your explanation that totally make sense. Could it be reflected in the documentation somehow? Maybe a short line anywhere, as I didn't find anything.
>Right, in some cases you have a non-abstract entity with some non-abstract entities extending it. If you want each of those classes in its own index, you will have to use @Indexed(index = "myIndexName" on the child classes.
Right, as pointed out, I missed here the notion of non-default:
>The keyword in those comments is the "non default" index name
Thanks for an explanation, & , could someone please close the ticket then, as it works as designed?
works as intended
Thanks, closing this.
Regarding your setup, I'd highly recommend to not use "shared writers". Best to point each app to a separate index, or if you really want them to share "index state" it might be preferrable to setup a JMS backend: https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#search-architecture-jms