IndexSchemaManagementStrategy#NONE throws an exception if index does not exist
Activity
Yoann RodièreJanuary 31, 2017 at 9:57 AM
> but then again org.hibernate.search.FullTextSession#createIndexer 'creates index' and populates them so I don't really need them to pre-exist
Be careful, this method creates an Index*er* (in other words, an index populator), not an index. If the index does not exist, the mass indexing will fail.
When you use the NONE strategy, you have to create the indexes and mapping on Elasticsearch yourself. Hibernate Search will not do it, neither when starting up nor when mass indexing.
In your case, the CREATE or MERGE strategies indeed seem to make more sense. Be careful about the MERGE strategy in a production environment, though (see the docs for a detailed explanation).
> i suspect it may affect the application startup time.
It will, but then your application will not be fully started until you reindexed everything, which requires to create the indexes, so...
> For me it is just confusing that IndexSchemaManagementStrategy.NONE actually checks for indexes existens...
I agree. PR coming.
Aliaksandr LaptseuJanuary 31, 2017 at 9:32 AM
Hi Yoann,
I would recommend to at least create the indexes before starting Hibernate Search, even if you only populate them after startup. But then it's your choice...
This is what IndexSchemaManagementStrategy#MERGE option does for me. And then I populate them after startup (for a first time or if i dropped them) using org.hibernate.search.FullTextSession#createIndexer (which takes several hours to finish due to amount of data) , but then again org.hibernate.search.FullTextSession#createIndexer 'creates index' and populates them so I don't really need them to pre-exist (may be it's just my case), also i suspect it may affect the application startup time.
For me it is just confusing that IndexSchemaManagementStrategy.NONE actually checks for indexes existens...
Thanks for clarification
Yoann RodièreJanuary 31, 2017 at 9:09 AM
I don't understand: if everything worked as you wanted, would you create the index yourself or expect Hibernate Search to do it "lazily"?
I'll assume that you want to create it yourself, since lazy index creation is not a feature we intended to provide (even though it's probably possible to achieve it by abusing dynamic sharding).
Actually I did not think of your use case at all; to me the index would always be pre-existing, I assumed the purpose of the NONE strategy would primarily be to allow to circumvent issues with the VALIDATE strategy. In which case, being able to wait for the index to be ready (green or yellow) would be useful.
I'm not sure it's a good idea to start Hibernate Search before the underlying indexes even exist: there is currently no need for Hibernate Search to inspect the index when starting up, but this may change in the future... I would recommend to at least create the indexes before starting Hibernate Search, even if you only populate them after startup. But then it's your choice...
Anyway, regardless of whether it's a good idea or not, it seems a bit strange indeed that the "none" strategy means "do nothing except...".
It seems like a easy fix, I'll submit a PR and we'll see what others think about it. If everyone agrees, we'll merge it.
Details
Assignee
Yoann RodièreYoann RodièreReporter
Aliaksandr LaptseuAliaksandr LaptseuLabels
Fix versions
Priority
Major
Details
Details
Assignee
Reporter
Labels
Fix versions
Priority
Major
Not sure that this is a correct implementation:
if ( schemaManagementStrategy == IndexSchemaManagementStrategy.NONE ) { schemaCreator.checkIndexExists( actualIndexName, schemaManagementExecutionOptions ); return false; }and
org.hibernate.search.elasticsearch.schema.impl.DefaultElasticsearchSchemaCreator#checkIndexExistsIn previous versions (beta2..3..4) it wasn't the case...
In my case some indexes or all of them may not exist during application initial startup and I am going to do on demand full reindexing to recreate them.
Workaround for me now is to use IndexSchemaManagementStrategy#MERGE option