Search mapping for core type collection

James Minter · **Joined:** Tue Oct 09, 2007 4:48 am **Posts:** 11

Hi,

Sorry for being so dull here, but I just can't see where I'm going wrong...

I have things persisting nicely to hibernate, and getting indexed.

However, I am now trying to map a simple java.lang.String set so that I can query against elements in the set.

The relevant bit of code looks like this:

Code:

@org.hibernate.annotations.CollectionOfElements
@JoinTable(name="videoassettag",joinColumns=@JoinColumn(name="videoassettagid"))
@Column(name="tagname", nullable=false)
@Field(index=Index.UN_TOKENIZED, store=Store.NO)
private Set<String> tags = new HashSet();

This gives me this stack:

Code:

Caused by: org.hibernate.search.SearchException: Unable to guess FieldBridge for tags
   at org.hibernate.search.bridge.BridgeFactory.guessType(BridgeFactory.java:180)
   at org.hibernate.search.engine.DocumentBuilder.bindFieldAnnotation(DocumentBuilder.java:321)

Which makes sense, but I'm not clear on what fieldbridge I'm supposed to be using, or even if that is the correct method. Can't see an example in the ref. guide.

I've tried using @IndexEmbedded, but that didn't help (didn't get an exception, but didn't index the set either).

Many thanks for any light you can shed on this,

James.

hardy.ferentschik · **Posted:** Tue Jan 08, 2008 4:57 pm

The problem is that there is no default bridge to map Set<String>. The easiest way to move forward would be to implement a custom StringBridge (http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e1505) and then use the @FieldBridge(impl = MyStringSetBridge.class) annotation.

@IndexedEmbedded is intended for indexing entities not built in Java types.

Hope this helps.

James Minter · **Joined:** Tue Oct 09, 2007 4:48 am **Posts:** 11

Thank you for the reply.

To confirm I understand:
The point of the custom StringBridge would simply be to iterate through all elements of the set, concatenating the values before finally returning a long string?

In this case, what meaning is there to tokenized/un_tokenized since it would just be storing one very long string (if there were a lot of long string elements in the set). i.e. we lose the delineation of the values.

If, say, I remove or add a String to the Set, presumably hibernate will manage the addition/removal from the index? i.e. this kind of scenario is not the famed HSEARCH-56 re-index issue?

Thanks again for the help.

James.

emmanuel · **Posted:** Wed Jan 09, 2008 6:57 am

Hardy is right, actually we should propose that in Hibernate Search. Can you open a JIRA issue.

Not sure what you mean by delineation, but yes you denormalize the collection. I agree that UN_TOKENIZED then does not make sense. Tokenized remains valid though since you can find tokens belonging to the collection of strings.

I don't think collection of elements are affected by HSEARCH-56, but it worths a try. I've added a comment to take care of that.

hardy.ferentschik · **Posted:** Wed Jan 09, 2008 9:35 am

James Minter wrote:

Thank you for the reply.

To confirm I understand:
The point of the custom StringBridge would simply be to iterate through all elements of the set, concatenating the values before finally returning a long string?

Sorry, what I actually meant was FieldBridge. If you use a StringBridge you have to - as you mentioned - concatenate the strings in the set.

A FieldBridge would be nicer. You could just add iterate over the set and add each entry as new Field. That's how indexed a Collection<String> entry in one of the applications I was building.

Code:

public void set(String name, Object value, Document document, Field.Store store, Field.Index index, Float boost) {
                    
Set<String. entries = (Set<String>) value;
for (String s : entries) {
        Field field = new Field( name, s, store, index );
        if ( boost != null ) field.setBoost( boost );
        document.add( field );
}

emmanuel · **Posted:** Wed Jan 09, 2008 7:29 pm

Hardy, adding several fields with the same name end up adding a single field concatenated :)

WhiteAndNerdy · **Joined:** Wed Jan 09, 2008 10:51 am **Posts:** 4

I had a similar situation and solved it with a bridge that just concatenates. It seems that collections of elements are affected by HSEARCH-56. No matter how I changed the collection. I still had to index each updated entity by hand.

emmanuel · **Posted:** Thu Jan 31, 2008 12:10 pm

I have commited a prototype that fixes HSEARCH-56 but the code on the Hibernate Core side needs to be polished.