I am a beginner to Hibernate. I am browsing many web tutorials which is confusing me. I just want to know the direction which to go with searching when using Hibernate.
Some tutorials are telling use Hibernate Search with Lucene, other saying use criteria while other saying createSQLQuery.
Can someone guide me in this ?
You should start with Hibernate-Core read the Tutorial and test the examples, modify them. This is IMHO the best way to become familiar with a (any) framework.
Lucene is used by Hibernate-Search which is an extension to Hibernate-Core to index text fields and provide full text search. Don't get confused by the extension unless you managed the core functions.
Related
I'm finding a full-text search framework to search my blog, i have seen solr getting started, but i find solr it's black-box framework, in my experience, if it raise some error, it will hard to debug and know what happen in its inner code.
so my question is is there java search framework that i can use it with pure java(without xml or bin)?
Solr is open-source, you can see it here http://lucene.apache.org/solr/
You normally would not need to debug it to begin with. Solr just wraps the Lucene engine in a REST API with a nice web interface so what would really your problem be?
If you want alternatives, nowadays the best/only alternative with lots of support would be elastic search, you can read more here http://www.elasticsearch.org/overview/
Have a blast.
we use Hibernate Search in our application. We use faceting. Recently we have found a big limitation. Faceting over fields that can have multiple values doesn't work properly with Hibernate Search - if a document has multiple values for faceted field (ex. multiple categories), only one of the values is taken into account.
I can currently think of a couple two solutions:
use bobo-browse (http://code.google.com/p/bobo-browse/)
solr (http://lucene.apache.org/solr/)
In both solutions we continue to maintain the index using Hiberante Search and making queries as we did before (using Hiberante Search), and run additional bobo-browse or solr query for faceting, where required (bobo-browse or solr would use index in kind of "read-only" manner). The problem is that we update index quite often, and would like to get really fresh data in faceting queries. Bobo-browse doesn't automatically integrate with Hiberante Search, and to keep search up to date, I might get into some problems (ex. https://groups.google.com/forum/?fromgroups=#!topic/bobo-browse/sn_Efc-YClU). The documentation looks a bit untidy and not yet completed. Solr on the other hand seems like a really big thing to add, just to get faceting work properly. And I'm still afraid I might run into some problems with updating/refreshing index.
Do you have any experience in that matter? Any suggestions?
As a Hibernate Search developer, I'd suggest to join us and help implement what you need.
Noone of us actually needed multivalued faceting so we're not really sure which solution to pick either; it seems you have a real need, that's perfect to explore the alternatives and try them out.
Hibernate Search already depends on many Solr modules especially because of the large collection of excellent analysers. I'm confident we could find a way to embed the faceting logic of Solr and package it nicely in our consistent API, without the need to actually start Solr in server mode.
I guess we could do the same with Bobo-browse; I'd prefer Solr to not add other dependencies, but if bobo-browse proofs a superior solution why not.. but you can help us in this choice.
What would you get in exchange?
we'll maintain it: compatibility will stay with any future version. hopefully you'll help a bit.
eternal gratitude from other users ;)
rock solid testing from thousands of other users
bugfixes and improvements from ..
a rock star badge on your CV
What is required?
unit tests
documentation updates
sensible code
https://community.jboss.org/wiki/ContributingToHibernateSearch
I also use Bobo Browse in combination with Hibernate Search. I also have the problem with regular updates and the read-only issue. Bobo is not the easiest library out there and I've looked several times at ways to integrate with Hibernate Search and just gave up because of the complexity.
I use timed reloads of the index in order to ensure freshness but that creates a lot of garbage to be collected. Lucene has over time optimized the process of reopening indexreaders, but the Bobo team is not really focused on supporting that. https://linkedin.jira.com/browse/BOBO-31 describes this issue.
The Hibernate Search infrastructure should provide enough flexibility to integrate. Zoie is a real-time indexing system like Hibernate Search that is integrated with Bobo https://linkedin.jira.com/wiki/display/BOBO/Realtime+Faceting+with+Zoie Perhaps it can inspire your efforts
This is something of a solution to the multi-value facet-count problem for hibernate-search.
Blog: http://outbottle.com/hibernate-search-multivalue-facet-counts/
The blog is complete with a Java Class that can be reused to generate facet-counts for single-value and multi-value fields.
The solution provided is based on the BitSet solution provided here: http://sujitpal.blogspot.ie/2007/04/lucene-search-within-search-with.html
The blog has a Maven project which demonstrates the solution quite comprehensively. The project demonstrates using the hibernate-search faceting API to filter on....
a date-range AND a 1-to-many (single-value) facet-group AND a many-to-many (multi-value) facet-group combined.
The solution is then invoked to correctly derive facet-counts for each facet-group.
The solution facilitates results similar to this jsFiddle emulation: http://goo.gl/y5C9UO (except that the emulation does not demo the range faceting).
The jsFiddle is part of a larger blog which explores the concept of facet searching in general: http://outbottle.com/understanding-faceted-searching/. If you’re like me and are finding the whole notion of facet-searching quite confusing then this will help.
It may not be the best solution in the world so feel free to feedback.
I'm looking for a tutorial about faceted search using java and lucene 3.6. I don't want to user solr. I need something that describe the steps needed to make the index (with categories, etc.) and how to do the search, classes and methods to use, etc. Thanks in advance...
I think this may help you.
It is official user guide.
1. http://lucene.apache.org/core/3_6_1/api/contrib-facet/org/apache/lucene/facet/doc-files/userguide.html
2. http://shaierera.blogspot.com/2012/11/lucene-facets-part-1.html
Here is a a tutorial for generating a quick Lucene search - http://www.hascode.com/2010/03/how-to-build-a-quick-lucene-search/
It might be a bit too basic for you though
But on the same blog there's a tutorial how to achieve faceting using Hibernate Search so there is Lucene and JPA under the hood but perhaps this is not a combination that you're searching for:
http://www.hascode.com/2012/03/hibernate-search-faceting-discrete-and-range-faceting-by-example/
In the Lucene 4.x documentation there's a whole chapter about this topic but it is an early release:
http://lucene.apache.org/core/4_0_0-ALPHA/facet/org/apache/lucene/facet/doc-files/userguide.html
If you've found a better source, please keep us up to date :)
Is beans binding for JTrees currently supported? I've found this forum post from 2008, but I didn't know if there was any development.
If it does exist does anyone know where i might find some documentation on it?
There is no beans binding, but the closest thing I know of would be NetBeans Nodes API with Explorer API. Using BeanNode and BeanTreeView ordinary Java Beans would be quite easy to bind to a JTree. This http://platform.netbeans.org/tutorials/nbm-nodesapi2.html tutorial goes much deeper, but the basic idea should be there. Depending on your use case this might not be that useful, but I find Node much easier to work with than pure TreeModel.
I can't seem to find any recent talk on the choice. Back in '06 there was criticism on Hibernate Search as being incomplete and not being ready to compete with Compass, is it now? Has anyone used both and have some perspective on making the decision.
I am developing a web app in Java in my free time, its just me so I'm looking to cut corners everywhere possible while minimizing the effect on the end product. Having said that the searching capabilities of my project are priority one! I have spent a good deal of time making the database model to back the system. The ability to get the user what they're looking for is what will set my app apart. So, speed is expendable ...obviously to a reasonable degree.
Here are my current thoughts on the technologies for this app, and if you see any glaring newb mistakes be gentle ...I'm an expert at nothing.
DB: PostgreSQL
Platform: Java
Frameworks: Spring, Hibernate, Seam
Obviously, I've chosen all free (as in beer) technologies and ones that as far as I can tell play nice together. So what do you guys think, Compass or Hibernate Search to round things out?
-Nomad311
<Careful. Biased person here: I am the project lead of Hibernate Search and author of Hibernate Search in Action by Manning>
If you are targeting Hibernate as your persistence provider, I think you are better off using Hibernate Search as the integration is very smooth (configuration, entity discovery down the the same APIs and programamtic model).
If you want to index a lot of "stuffs" that are not in your database, then Compass is a better fit.
We are working on Hibernate Search 3.2 at the moment: our road map is here
Hibernate Search is a complete product, and it's based on Lucene, which is one of the fastest open source search engine out here.
As an example, some benchmarks:
http://developers.slashdot.org/story/09/07/06/131243/Open-Source-Search-Engine-Benchmarks
Plus, it's fully integrated with Seam and Hibernate (look at the example in the Seam dist).
I suggest you to be more specific about:
Hibernate Search as being incomplete
I'd like to know in which part it is incomplete.
Compass is no more as of elasticsearch is new one after compass. So I think better to use some stable one. (Possibly Hibernate Search)