views:

248

answers:

2

I am using Hibernate Search and applied Lucene indexing on one table for a domain object. I want now to make selection from this table for domain objects and apply filtering based on joining with other table, which is not indexed.

For exampple, I have Auction Lots table, which I have indexed. And I have Quotes table. Quotes have references to Auction Lots.

I want to conduct full test search in AuctionLots table and return matched entities which have no quotes. In ordinary SQL this would achieved by JOIN.

But in the situation with HibernateSearch, I have to make full test search in order to obtain domain objects, but I don't know how to perform filtering with JOIN.

Does any body have an idea how to do this?

+1  A: 

I don't recommend filtering when creating the indexes for your search. Mainly because it is not supported by Hibernate Search as far as I know, but also because it makes no sense. What you should do in my opinion, is index the object you want to search for, including the relations to the 'child' objects. I assume your ActionLot object has a one-to-many relation to your Quotes objects. With the @IndexEmbedded annotation, you can mark your Quotes as objects which should be indexed as well. When you search for the ActionLots without quotes, you can filter this during your search using either restrictions in your search query, or by applying a global filter to your search. This can be done using the filter options provided by Hibernate Search.

Martin Sturm
Thank you! But don't you think, that indexing frequently changing data such as Quotes is slightly wrong?
glaz666
I don't know how often it changes, but I don't think it will be a big problem. Lucene (used by Hibernate Search) has a pretty decent indexer which is optimized for speed and postpones the indexing if necessary. To make your index less big, you can use a [ClassBridge](http://docs.jboss.org/hibernate/stable/search/reference/en/html_single/#d0e2466) to merge the fields of Quotes into one Lucene field.
Martin Sturm
+1  A: 

Using @IndexEmbedded or a ClassBridge is definitely the right approach. Also changing data should not cause a problem. That's what automatic indexing is for. You don't have to re-index all the data each time a Quote changes. Relying on auto-indexing will ensure that only the added/updated data gets re-indexed. As a note - if you want that the index for an ActionLot instance to be updated when the related quote changes, you need to have a bi-directional relationship and use @ConstainedIn

--Hardy

Hardy