Hi,

We have a rather intricate search idea. For this we are starting to get a rather large set of unit tests (or componentTests / FacesRequest-tests in Seam to be specific) that verifies and maintains the idea. Running this set is becoming very slow and requires the embedded setup and teardown as well as a database.

I previous projects where I only used Lucene it was freakingly simple to unit test en masse by setting up a RamDirectory, fill that with some documents, fire off some probing questions and finally verifying the result. This was completety standalone and as such very quick.

This leads to some questions: Can I use HibernateSearch during testing without the "db/environment"-setup? I realize I could ditch the embedded part ... but I guess I no matter what will need an EntityManager ... which requires a db or?

In short: Can the quick standalone (no DB) ramdir-testing be attained while still using HSearch?

Thankful for any suggestions on this,
Tobias

No but yes.

Here is how I unit test. I run HSQLDB or H2 as my database (in memory). I run my Search unit tests with the RAMDirectory

hibernate.search.default.directory_provider=org.hibernate.search.store.RAMDirectoryProvider

My tests runs blazingly fast, I don't fear any data side effect (ie some left over from previous tests) and I run the whole chain (not "unit" tests per se).

Ok good point, thanks.

Related:
Suppose I just want to use the indexing functionality of HibernateSearch as a way to index to a RamDir without usage of fulltext-entityManagers etc. That would be something that takes an annotated class and returns a LuceneDoc. I've found DocumentBuilder<T> in the Api-doc which might be what I need? ... but I am uncertain on how to use it. The javadoc does not really give any clues either.

In short: Is there any (fairly easy to use) class-to-lucenedoc-converter decoupled from entity-managing in hsearch? If so, could you briefly sketch a usage?

/Tobias

DocumentBuilder is the way to go, but this is an internal API so it can change over time.