There were several changes to the package name and class between Hiberate 3.x and 4.x, so the code that works with Hibernate 3.x will not work with 4.x, except in rare cases. In addition to changing the name, there have been major internal changes in the work, so the code that compiles will not necessarily run. Variant of application No. 1 - transition to Hibernate 3.x. The configuration settings for this are included and commented out (BuildConfig.groovy, DataSource.groovy), so this is a very quick option. Obviously, this is not an option if you depend on a feature added in 4.x, and that just delays the real problem until you have to update Hibernate.
All plugins that use Hibernate 3 need to be updated to support Hibernate 4, either as a replacement, or ideally supporting both the use of cross-compilation tricks and other 3 rd party libraries. One version of the plugin, assuming that users will eventually be upgraded from 3.x, is to create a 3.x branch and start a new major revision of the plugin (in the main branch) for Hibernate 4 and make changes to make it work in 4. X . Use the 3.x branch to support security updates and very minor issues, but don't add new features. Probably many plugin authors will go this route.
In some cases, another option makes the most sense - do nothing. This refers to a search query. Searchable uses http://www.compass-project.org/ , which is virtually dead - its last release was 4 years ago. Shay Banon is now CTO at http://www.elasticsearch.org/ . I believe that Shay stopped working on Compass and started Elasticsearch because it is not practical to scale Compass outside of one server. You can save the Lucene index in the database, but while it gives you a centralized single writer and one or more (with db clustering or similar) centralized reader, an optimized search server with user protocols, etc. more sense.
There also Solr consensus seems to be preferred by Elasticsearch. The Solr Grails plugin did not update after 3 years, and the Elasticsearch plugin also became moldy, but recently Noam Tenne took on the role of the plugin and did a lot of work, and he has done several releases over the past few months. Note that the old elasticsearch and elasticsearch-gorm have been merged and updated to create a new elasticsearch plugin.
Another option is to use Hibernate's own product, Hibernate Search . There is a plugin for this , but it has not been updated since 2012. Selfishly, this is my personal preference for you - choose this option, take on the plugin (assuming a positive answer or no answer from the original authors) and update it so that it is compatible with the latest Hibernate 4.x plugin. This will give us a good alternative to Elasticsearch.
Banning this, I think Elasticsearch is your best option.
Burt beckwith
source share