Search 4.x equivalent to get DirectoryProvider for class?

kjordan2001 · **Joined:** Wed Nov 21, 2007 10:24 am **Posts:** 25

In 3.4.x I used FullTextEntityManager.getSearchFactory().getDirectoryProviders(MyEntityType.class) on the FullTextEntityManager I got from Search.getFullTextEntityManager(myEmf) to get whatever directory provider I was using on a particular class type for different environments. However, that's gone and I can't seem to find how to get where my indexed objects for that class will get stored using what provider. Is there an equivalent for 4.x that I'm not seeing?

sanne.grinovero · **Posted:** Wed Dec 28, 2011 9:10 am

Hi,
indeed that changed a bit, mostly because it's not a requirement anymore to use Directory based indexes (to make it possible to use alternative indexing engines);
so assuming you really need to access the Directory the code now would look like as:

Code:

SearchFactoryIntegrator searchFactoryIntegrator = (SearchFactoryIntegrator) fullTextSession.getSearchFactory();
EntityIndexBinder snowIndexBinder = searchFactoryIntegrator.getIndexBindingForEntity( SnowStorm.class );
IndexManager[] indexManagers = snowIndexBinder.getIndexManagers(); // it's an array as sharding might be enabled
DirectoryBasedIndexManager indexManager = (DirectoryBasedIndexManager) indexManagers[0];
Directory directory = indexManager.getDirectoryProvider().getDirectory();

Some new concepts:
EntityIndexBinder is a place where you can access several services bound to a specific indexed type.
IndexManager manages an index and all it's related services - you get an array from getIndexManagers() because of possible sharding options.
DirectoryBasedIndexManager is the only one exposging a getDirectoryProvider() method, as other (future) implementations might not need to be Directory based.

Generally, why do you need to access the Directory?
If it's only to read the Index directly, there is this much easier:

Code:

fullTextSession.getSearchFactory().getIndexReaderAccessor()

kjordan2001 · **Joined:** Wed Nov 21, 2007 10:24 am **Posts:** 25

s.grinovero wrote:

Hi,
indeed that changed a bit, mostly because it's not a requirement anymore to use Directory based indexes (to make it possible to use alternative indexing engines);
so assuming you really need to access the Directory the code now would look like as:

Code:

SearchFactoryIntegrator searchFactoryIntegrator = (SearchFactoryIntegrator) fullTextSession.getSearchFactory();
EntityIndexBinder snowIndexBinder = searchFactoryIntegrator.getIndexBindingForEntity( SnowStorm.class );
IndexManager[] indexManagers = snowIndexBinder.getIndexManagers(); // it's an array as sharding might be enabled
DirectoryBasedIndexManager indexManager = (DirectoryBasedIndexManager) indexManagers[0];
Directory directory = indexManager.getDirectoryProvider().getDirectory();

Some new concepts:
EntityIndexBinder is a place where you can access several services bound to a specific indexed type.
IndexManager manages an index and all it's related services - you get an array from getIndexManagers() because of possible sharding options.
DirectoryBasedIndexManager is the only one exposging a getDirectoryProvider() method, as other (future) implementations might not need to be Directory based.

Generally, why do you need to access the Directory?
If it's only to read the Index directly, there is this much easier:

Code:

fullTextSession.getSearchFactory().getIndexReaderAccessor()

I had some code written where I did a copy of memory-based indexes, including a clustered one through things like Hazelcast which doesn't always guarantee a backup of what's in memory, to an FSDirectory for backup and in some of my environments it hasn't switched to that yet so I have to check if it's using a FSDirectory or a memory-based directory. Thank you for the code sample, I had seen the IndexManager and other things there, but I hadn't run across the SearchFactoryIntegrator yet.

sanne.grinovero · **Posted:** Wed Dec 28, 2011 1:06 pm

Quote:

I had some code written where I did a copy of memory-based indexes, including a clustered one through things like Hazelcast which doesn't always guarantee a backup of what's in memory, to an FSDirectory for backup and in some of my environments it hasn't switched to that yet so I have to check if it's using a FSDirectory or a memory-based directory. Thank you for the code sample, I had seen the IndexManager and other things there, but I hadn't run across the SearchFactoryIntegrator yet.

Interesting! Note that org.hibernate.search.indexes.impl.DirectoryBasedIndexManager should be easy to extend, and likely a good place to have some index-maintenance code.
The "big thing" of 4.0 was the introduction of this new architecture; there are already some extensions in the code base, for example NRTIndexManager, but for 4.1 we would like to add more alternative IndexManager implementations; it would be very nice to have an Hazelcast one, if you want to contribute it.