Hibernate 3.6.0, HSearch 3.3.0. Quick newbie question regarding the QueryBuilder.

I have an ItemEntity and some derived entities, in my demo app I have a WineEntity with specific indexed fields concerning bottles of wine. My question is, can I use a QueryBuilder built for the parent class ItemEntity to build queries for attributes of WineEntity, or will I have to use the Lucene API directly to add such a field query?

I have found that the QueryBuilder's keyword() builder can only specify onField for attributes of ItemEntity. You cannot specify fields for subclasses such as WineEntity.



Now I prepare a QueryBuilder for ItemEntity, and later try to tell it to query on an attribute that actually belongs to a child class of ItemEntity:



throws:



The documentation under "5.1. Building queries" is good, and in 5.1.2 pushes us to use the HSearch DSL API for preference, but doesn't specify the details of using it with polymorphic entity classes.

Should I not use the DSL API, and build a Lucene query term directly?

Thank you
Nick

You can use the QueryBuilder targeting the subclass, and then still target the Query to the superclass to include types which don't have an appellation field.

I don't think this usage was expected, but please help us figuring out how it would be more easy to use. Would you expect the QueryBuilder to know all fields of subtypes? What would you expect from:
?

In my case, I don't want to build the QueryBuilder targeting the subclass, because my app works on the basis of a core ItemEntity class, with any number of possible child Entity classes for each customised environment I deploy to. The frontend passes to the backend all fields to search on, and my generic search utils build the Queries required to search on those fields. The 'appellation' field name is passed into my generic search code from a customised frontend. The core code only knows about the parent ItemEntity class, and not about the child WineEntity which has the appellation field. (the WineEntity instances themselves are created and indexed via another set of custom code).

So, I wanted to always build a QueryBuilder for my parent class, but be able to specify onField() clauses for fields that are found on child classes.

I know this goes against standard OO practise.. but in the world of Lucene indexes, the index will contain fields for both parent and child class, i.e.:

_hibernate_class: my.app.WineEntity
coreItemField: 1000
appellation: foobar

(in case you're wondering, yes, this is a completely different problem to the @IndexEmbedded JIRA I raised recently)

I see via Luke that the _hibernate_class indicates what Entity class should be used to instantiate this object.. to be honest, I don't yet understand how to think about the mapping of Java Entity classes to Lucene index Documents.



Good question. QueryBuilder should only know to act on @Indexed classes, and hopefully the job of inspecting them and all subtypes is fairly straightforward, if not already done at SessionFactory instantiation time.

I did hope that QueryBuilder would know all fields of subtypes. But, perhaps QueryBuilder is doing The Right Thing, and I should approach the problem differently. In OO terms, it doesn't make sense to have a reference of the type of the parent class and expect it to know about members in derived classes; the inheritance system works the other way, a reference to a child class would naturally know about members of parent classes/interfaces. I don't know if it is a good idea to build this kind of introspection into HSearch.

For now, I work around by catching a SearchException when trying to specify onField for every field specified, and for those that fail, I build a plain Lucene TermQuery, knowing that Lucene's index will contain the field, even if HSearch cannot figure out what I'm talking about. Perhaps I will run into trouble with the analyzers and tokenizers used on the field.. I haven't read over the docs enough times for that complex info to sink in yet :)

Nick

Referring to Object.class is an exaggeration of course, but I wanted to point out that they are potentially many different types; also as we have to choose the analyzer for each field, this means we would need to mandate unique names across all indexed entities.

I think you should use the DSL to create a Query targeting the parent entity, and then use a BooleanQuery to combine it with additional keyword queries. Remember, if you use the TermQuery directly you'll have to pre-Analyze the input yourself before building the Query, or rather use a queryparser targeting the additional nonstandard fields; hopefully your frontend is able to tell you the Analyzer types too, or you use a single conventional Analyzer for all.

Another option, your frontend tells you the target type it's searching for.