The other day I finished going through this new Manning book on Hibernate Search. This is basically a good book, and is useful. I still think Hibernate Search itself is great thing. I can hear a lot of longtime Lucene users grumbling about the fact that all HS is doing is wrapping their brilliance (and then, we can all hear the obvious next sniggering smear: the HS programmers must have grown up on a diet of C++, the wrapper language). But in this case, the wrapping is a very good thing, and very well done. Generally speaking, you have to give Red Hat props: since acquiring Hibernate, all the things you liked about it: solid releases, good documentation, some vision, has remained good, and other things have gotten better. Anyway, onto my 2 burning questions:
My first question was will HS let me do a query where some constraints are expressed in terms of fields, and some as text, e.g. show me all Classifieds between dateX and dateY that have these keywords. As is often the case, this question started to become a kind of make or break in my mind. For this thing to really transcend mere wrapper, it seemed to me that this needed to come home in some fashion. Shocking news: it doesn‘t and the whole question does not seem to be a major concern of either these authors or the guys who wrote the docs. Am I crazy to think this would be top or top 3 of a FAQ that was ranked on # of times asked?? Well, it turns out that after you wind through the minotaur‘s maze in this book, you find out that there is no way, and the whole question is kind of dismissed as ‘think about it, you would have wrong counts since the things are fetched from different places.‘ Now, the grumpy, vinegary sod in me (read: the one who is around 90% of the time here) reads something like this and thinks ‘wait, are you jokers kidding me??? Do you know what SQL is based on? Set theory kiddies. We are just asking for a product for chrissakes, how hard can that be to fetch??‘ But it‘s 2009, and I am feeling like I ought to be less grumpy this year. So instead, my reaction was ‘ok, we can work with this…‘ (partially because there is a kind of middle ground: the date field can be annotated and the range can be done on the fulltext side).
I predict that at some point in the future, this issue will become more central. I think HS may have missed the best argument for its existence by punting on this, but as I stated above, I still see great utility in it, but I have less resistance to new things than a lot of places will.
You probably noticed by now that I am coining my own phrases for these things which is admittedly suboptimal, but here I am meaning searches that can return multiple types . Consider Amazon: you search for ‘salmon‘ and you get things from books to food to clothing (it‘s a color). The other thing that seemed a total natural here since Hibernate is wrapping results as entities, would be for it to make these types of searches possible, or at least address how best to do these. There are really two choices: do one search and have the results bucketed for you, or do a search for each type and bucket them yourself. This book recommends the latter. I didn‘t really care on this one, didn‘t feel like the framework was blowing out on us. Rather, I was happy to see a recommendation. This is one place where the docs are kind of lacking: examples of these two things should be featured, and prominently.
Per my earlier post, a lot of my work with this now is under the rubric of Fresco, our code generation tool we are developing. Search is one of the best greenfields we have wandered into. After poking around with this now for a while, I am more convinced than ever that no one should hand write search ever for any reason. People who tell you otherwise are nuts. This is a perfect use of code generation, and some ubersearch component is not possible.