[search 3.3.0.Final] Indexing nulls with @IndexedEmbedded

misieq · **Joined:** Tue Jan 18, 2011 9:01 am **Posts:** 4

Hello all,

we currently upgraded hibernate search to 3.3.0.Final to be able to simplify null values indexing with idexNullAs property of @Field annotation. However we can't get it working with an embedded entity using @IndexedEmbedded without a field bridge. An example worth a 1000 words is joint below :)

Code:

@Indexed
@Entity
public class A {

@Id
private Long id;

@Field(indexNullAs = Field.DEFAULT_NULL_TOKEN)
private String simpleProperty;

@Field(indexNullAs = Field.DEFAULT_NULL_TOKEN)
@IndexedEmbedded
private B complexProperty;

}

@Entity
public class B {

@Id
private Long id;

@Field
private String anotherProperty;

}

This code will throw 'org.hibernate.search.SearchException: Unable to guess FieldBridge for B' exception while indexing (but will work like a charm for a simple String property). We are obliged to add a FieldBridge for B then and manage nulls indexing inside anyway.
Are we using those annotations in a wrong way? Is the exception due to some technical constraint or can this feature be logged as an evolution for future versions?

Thanks in advance for your help and opinions!

hardy.ferentschik · **Posted:** Tue Jan 18, 2011 11:41 am

Hi,

could you post the full stacktrace?

misieq · **Joined:** Tue Jan 18, 2011 9:01 am **Posts:** 4

sure, there you go:

Code:

Exception in thread "main" javax.persistence.PersistenceException: [PersistenceUnit: persistence-unit] Unable to build EntityManagerFactory
   at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:911)
   at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:74)
   at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:225)
   at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:308)
   at xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.LuceneIndexer.main(LuceneIndexer.java:33)
Caused by: org.hibernate.HibernateException: could not init listeners
   at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:205)
   at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1980)
   at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1842)
   at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:902)
   ... 4 more
Caused by: org.hibernate.search.SearchException: Unable to guess FieldBridge for complexProperty
   at org.hibernate.search.bridge.BridgeFactory.guessType(BridgeFactory.java:250)
   at org.hibernate.search.engine.AbstractDocumentBuilder.bindFieldAnnotation(AbstractDocumentBuilder.java:690)
   at org.hibernate.search.engine.AbstractDocumentBuilder.checkForField(AbstractDocumentBuilder.java:564)
   at org.hibernate.search.engine.AbstractDocumentBuilder.initializeMemberLevelAnnotations(AbstractDocumentBuilder.java:432)
   at org.hibernate.search.engine.AbstractDocumentBuilder.initializeClass(AbstractDocumentBuilder.java:379)
   at org.hibernate.search.engine.AbstractDocumentBuilder.init(AbstractDocumentBuilder.java:341)
   at org.hibernate.search.engine.AbstractDocumentBuilder.<init>(AbstractDocumentBuilder.java:120)
   at org.hibernate.search.engine.DocumentBuilderIndexedEntity.<init>(DocumentBuilderIndexedEntity.java:147)
   at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:380)
   at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:262)
   at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:144)
   at org.hibernate.search.event.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:137)
   at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198)
   at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181)
   at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194)
   ... 7 more

Sorry, I should have posted that directly. xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.LuceneIndexer is actualy our main class that is responsible for idexing :

Code:

public static void main(String[] args) throws SQLException {
      BasicDataSource dataSource = new BasicDataSource();
      dataSource.setDriverClassName("com.mysql.jdbc.Driver");
      dataSource.setUrl("jdbc:mysql://localhost:3306/my_schema");
      dataSource.setUsername("username");
      dataSource.setPassword("pass");

      LocalContainerEntityManagerFactoryBean entityManagerFactory = new LocalContainerEntityManagerFactoryBean();
      entityManagerFactory.setDataSource(dataSource);
      entityManagerFactory.setPersistenceUnitName("persistence-unit");
      HibernateJpaVendorAdapter hibernateJpaVendorAdapter = new HibernateJpaVendorAdapter();
      hibernateJpaVendorAdapter.setDatabase(Database.MYSQL);
      entityManagerFactory.setJpaVendorAdapter(hibernateJpaVendorAdapter);
      entityManagerFactory.afterPropertiesSet();

      EntityManager entityManager = entityManagerFactory
            .getNativeEntityManagerFactory().createEntityManager();

      FullTextEntityManager fullTextEntityManager = Search
            .getFullTextEntityManager(entityManager);
      try {
         fullTextEntityManager.createIndexer().startAndWait();
      } catch (InterruptedException e) {
         throw new RuntimeException(e);
      } finally {
         dataSource.close();
      }
   }

hardy.ferentschik · **Posted:** Wed Jan 19, 2011 8:28 am

Hi,

I had another look at your example. The problem is @Field(indexNullAs = Field.DEFAULT_NULL_TOKEN) on complexProperty. Since B is a custom type there is no default field bridge to use and hence the exception.
@Field and @IndexedEmbedded are doing two different things and are independent of each other.

I guess you are looking for something like a @IndexedEmbedded( indexNullAs = Field.DEFAULT_NULL_TOKEN). That's indeed a missing feature. I am wondering how much sense it would make and how it would behave. For which fields would the null token be indexed. For each single field in the embedded instance, in this case id and anotherProperty? Or would you add a single new field with the null token to the document/index? If so, how woud you then search for it? You would need to add an explicit clause for this null field.

Feel free to elaborate what you want to achieve. Btw, keeping the additional @Field annotation and adding a custom bridge might be the best way forward.

--Hardy

misieq · **Joined:** Tue Jan 18, 2011 9:01 am **Posts:** 4

Hi Hardy,

Thanks for checking out on this.
Actually sort of @IndexedEmbedded( indexNullAs = Field.DEFAULT_NULL_TOKEN) is exactly what I would like to use in my case. It would be useful for expressing conditions in boolean queries.

My initial need is to query for all records that have complexProperty = null or complexProperty.anotherProperty = <searched_value>.

In my current solution I use a field bridge to create a new token in the index to hold information on complex property's value (whether it's null or not null). As for now I only need one property from my embedded object (complexProperty.anotherProperty) so I simply put its value in the index token when embedded object is not null. I don't know what would be a preferable solution for a more complex case. A global 'flag' index token for the whole object would let us differentiate between a null object and an 'empty' one (one having all indexed fields empty) and it seems to be a clean solution. But maybe we could think of another one that does not imply any index structure changes.

And maybe I'm complexifying the simple and there is another solution for my query problem...

Thanks again!
Michal

sanne.grinovero · **Posted:** Wed Jan 19, 2011 3:32 pm

Indeed @IndexedEmbedded(indexNullAs = Field.DEFAULT_NULL_TOKEN) seems to be a missing feature, if you could provide a patch we'll be glad to merge it. You can get some inspiration from @Field implementation, you should be able to do it in a couple of hours.

Still I'd keep it simple: just replace that token if the object is Null. Making a difference with an object whose all fields are null comes for free, when the first token is not found and the subfields are flagged.

If you have more complex requirements, then using a FieldBridge is the way to go.

hardy.ferentschik · **Posted:** Sun Jan 23, 2011 10:58 am

FYI, http://opensource.atlassian.com/project ... SEARCH-670

grizzkeys · **Joined:** Tue Aug 16, 2011 5:58 pm **Posts:** 6

hardy.ferentschik wrote:

FYI, http://opensource.atlassian.com/project ... SEARCH-670

I notice the issue is still unresolved, has there been any progress in determining the best workaround or what might be the fix for future versions? I appreciate you answering my questions as I continue learning more about the actual code functions, etc. Right now I only know how to conduct online file storage through the cloud and all of the functions included, which had left me desiring more especially on the IT side of things while I prepare my resume for an IT staffing agency somewhere down the road.

sanne.grinovero · **Posted:** Fri Aug 19, 2011 2:22 pm

Yes I think it will be available in version 4, a nice contributor just proposed a patch which is being reviewed&polished for inclusion.