Help

Inactive Bloggers

It’s my pleasure to announce the first maintenance release of Hibernate OGM 4.1! This version makes a few more data types usable for your entity properties (float, short, char), comes with several component upgrades (Hibernate ORM 4.3.8 and Infinispan 7.0.3) and fixes some bugs.

The latter were discovered by helpful users who gave Hibernate OGM a spin after 4.1 was out in December. Kudos to everyone testing the library and reporting bugs or feature requests, that’s much appreciated!

We see an increased interest in Hibernate OGM by means of questions in the forum. Keep those coming; specifically we’re looking forward to your feature proposals, so we know which functionality we should implement next to provide the most value for you. We are also monitoring the hibernate-ogm tag on Stack Overflow. So if that’s more your kind of thing, ask your question there and we’ll come up with an answer.

To give the new release a try, either download the release bundle from SourceForge or use these GAV coordinates with your preferred build tool:

  • org.hibernate.ogm:hibernate-ogm-core:4.1.1.Final for the Hibernate OGM engine and
  • org.hibernate.ogm:hibernate-ogm-<%DATASTORE%>:4.1.1.Final, depending on the backend you want to use.

Also let me use the opportunity to say a big Thank You to our community member Ajay Bhat who contributed the support for the new data types!

Finally, some useful links:

12. Jan 2015, 11:53 CET, by Sanne Grinovero

After the great news in December of the release of Hibernate Search 5.0.0.Final and the first stable (.Final) release of Hibernate OGM, we plan to keep updates coming regularly.

So today we introduce:

  • Hibernate Search 5.0.1.Final
  • Hibernate Search 4.5.3.Final

Both are considered stable; as expected for micro maintenance there was no need to update neither documentation nor the migration guide.

What's new in version 5.0.1.Final

  • updated to latest stable Hibernate ORM 4.3.8.Final
  • updated to latest stable Apache Lucene 4.10.3
  • improved some logging messages to be able to better help some users

What's new in version 4.5.3.Final

  • backported some backend changes like HSEARCH-1770, mostly useful to third party integrators such as Infinispan Query to improve their indexing efficiency.

WildFly 9 is coming

The source code of WildFly was updated to include our latest Hibernate Search 5. Looking forward to the final release of this super popular application server, as you won't have to download the Hibernate Search 5 dependencies separately!

How to get it

Everything you need is available on Hibernate Search's web site. Download the full distribution from here. And don't hesitate to reach us in our forums.

Stackoverflow

If you prefer to use stackoverflow.com, please use the tag hibernate-search. And if you have a moment to help other users, some please consider registering to the hibernate-search tag to help us answering all the questions.

If you are new to Hibernate Search, best is to start with our getting started guide. And remember: feedback, comments and/or pull-requests are welcome on the website too.

Next talk: JBUG London

Please remember I'll be talking about Hibernate Search 5 this Wednesday the 14th of January in London. There will be pizza, beers, and pub time to discuss anything related to Search.

These releases contain mostly minor bugfixes and improvements. For more information, please see:

Most changes applied to both versions. Of note are:

  • A new MySQL dialect (MySQL57InnoDBDialect) that adds support for fractional seconds HHH-8401;
  • NamingStrategyDelegator is now supported by standalone schema tools HHH-9467.

Other fixes made to 4.3.8 (only) were minor bug fixes and improvements.

JBoss Nexus: https://repository.jboss.org/nexus/content/groups/public/org/hibernate
Maven Central: http://repo1.maven.org/maven2/org/hibernate/hibernate-core (should update in a couple of days)

SourceForge: https://sourceforge.net/projects/hibernate/files/hibernate4
4.3.8.Final Downloads: 4.3.8.Final ZIP, 4.3.8.Final TGZ
4.2.17.Final Downloads: 4.2.17.Final ZIP, 4.2.17.Final TGZ

After 14 months of hard work, please welcome Hibernate Search 5 !

Let's have a look at the highlights of why you should be eager to upgrade:

  • Upgraded to Lucene 4.10
  • Lots of internal improvements, especially performance
  • Thanks to Hibernate Search abstraction, most of your code should be upgradable easily despite the massive changes in Lucene APIs
  • Numeric properties now indexed as NumericField by default
  • Requires JDK 7
  • Compatible with Hibernate ORM 4.3 and WildFly 8.x
  • Stable

How to get it

Everything you need is available on Hibernate Search's web site. Download the full distribution from here. And don't hesitate to reach us in our forums.

If you are new to Hibernate Search, best is to start with our getting started guide.

Feature list

Let's dive into the feature list.

Lucene 4.10

Hibernate Search 4 has been stuck with the quite outdated 3.6.x version of Apache Lucene, while the Lucene 4 series is introducing lots of improvements. Lucene has now reached version 4.10.3 and is considered stable, reliable and significantly more efficient than previous versions; you can now benefit from all these improvements. Some APIs changed, you might need to make some adjustments to your code such as Analyzer class names, but generally if you were using the Hibernate Search API, the most tricky changes of Lucene are encapsulated and won't affect your code directly.

Why version 5.0

The major number was increased because the Lucene upgrade is a significant change, and because it forced us to break our API compatibility promise which we apply on minor versions. Don't assume that this will require Hibernate ORM at version 5 too: it still depends on Hibernate ORM versions 4.3.x (as did Hibernate Search 4.5) and is still compatible with WildFly 8, and we expect it will be compatible with WildFly 9 as well. It is possible that Hibernate Search 5 will be compatible with ORM version 5; we'll certainly aim for that, but cannot guarantee it.

So if you have an application using Hibernate ORM 4.3.x and Hibernate Search 4.5.x, it should be simple to upgrade as you won't have to upgrade ORM and can focus on changes needed for Search and Lucene only.

Indexing Performance

The indexing engine has been revisited, providing great performance enhancements and also simplifying configuration: you no longer need to configure a number of backend workers.

Both asynchronous indexing and synchronous indexing have been redesigned.

For the asynchronous indexing backend you now have a per-index index_flush_interval property which you can use to limit the time between your updates committed on the database and the related index commit.

The synchronous backend is now able to merge write requests from multiple parallel transactions so to provide both the benefits of batched writes on the index while still having synchronous updates. This new model allows to have performance similar to what was previously only possible when selecting the NRT backend, but doesn't have the drawbacks such as not being compatible with the Infinispan Directory.

OSGi, Apache Karaf, JBoss FUSE

The project code and build has been refactored to produce nice OSGi compatible libraries. We run integration tests with Apache Karaf so our artefacts should be safe to consume via JBoss FUSE. The Lucene jars are still a bit troublesome, but if you have any problem with it please let us know we might be able to find a solution.

JDK 7, 8 and 9 compatibility

Hibernate Search 5 now requires a Java 7 runtime, but we also test regularly with Java 8 and previews of Java 9.

Automatic bridge discovery for property conversion

For those developers defining custom domain types, it's now possible to automatically bind a given Java type to a FieldBridge. You won't have to copy/paste those @FieldBridge annotations all over your model. This feature is explained in the BridgeProvider section of the documentation. You could use it for example to contribute the missing converters for Java 8 Date/Time types.

MoreLikeThis queries

Using the new MoreLikeThis query capabilities you don't have to target specific fields but can provide an instance of an indexed object. This model is also known as query by example and will trigger a similarity query matching all fields (or a subset of your choice). A full exaxmple can be seen on this previous blog post.

Dropped dependency to Apache Solr

Until this version Hibernate Search depended on Apache Lucene for most of the work, and also on Lucene's sister project Apache Solr to provide a richer set of analyzers. Since the Lucene project incorporated this functionality from Solr, there is no longer any need to depend on Solr artifacts.

Improved modularity: clean WildFly integration

With requirements such as OSGi support, other projects like CapeDwarf and Infinispan integrating Hibernate Search (but excluding dependencies to Hibernate ORM), advanced needs for the Hibernate OGM project our integration API and modularity was extensively stretched and tested, resulting in lots of improvements which you might not directly notice, but will make it much easier to avoid dependency conflicts with any other library you might use, or integrate nicely in your favorite container / framework.

One example is the new structure of the modules we provide for easy WildFly integration: highly encapsulated, and significantly less dependencies than previous versions.

For example the JGroups backend can use a JGroups version of your choice, and it doesn't need to match the JGroups version of Infinispan even if Hibernate Search is using Infinispan as well (which depends on its own JGroups version); this will not be a problem, and JGroups wouldn't even be exposed to your application so in theory you could be using a third different version of the clustering library in your app directly. In practice you would probably want to keep the versions aligned, but if you prefer otherwise it won't be a problem.

Numeric Fields

Any numeric property, including Calendar and Date types, are now by default indexed as a NumericField. A NumericField is more efficient to perform range queries, so we think this is what you should be using in most cases. Of course it's still possible to explicitly annotate the property to revert to the old behaviour: this is just a change in the defaults.

Please keep this change in mind when running queries, as you'll now need to query these as a NumericField. If you use our Query builder DSL this is going to be correct transparently, but if you use the Lucene native APIs to create queries the results won't match and you won't get any kind of warning.

Migration Guide

We normally keep track of any API change in our wiki's migration guide; that's the right place to look for API / compatibility changes between any specific version.

For a summary of the changes for people jumping from version 4.x to 5.x, we created a new dedicated Migration page on the website which you can find from the Documentation page.

Index Migration

Technically it is possible that this latest version of Lucene could read your existing indexes, but with such a large version increase of Lucene's code, and considering the numeric mapping changes, and the many changes in the Analyzers over time, we highly recommend you replace your old indexes and use the MassIndexer to trigger a fresh rebuilt.

What's next?

We have several interesting plans ahead, but our priority is defined by feedback. Please let us know what you'd need, or even if it works great for you it's nice for us to hear about it and what you do with it. You can get in touch with us with any of these media, especially the forums should be a good starting point.

This is what we hope to work in the near future:

  • dynamic defined models (not strictly bound to annotated classes)
  • Alternatives to embedded Lucene backends: Apache Solr or ElasticSearch seem to be good candidates for this
  • Support for the new Java 8 types
  • Integration in WildFly 9
  • Support for Forge
  • Openshift / Docker / Kubernetes templates and guides
  • Improve performance (Always!)
  • Improved clustering functionality (master election?) on Infinispan/JGroups
  • Take better advantage of the new Lucene 4 capabilities (Faceting, query-time join, etc..) Can you suggest?

This list is long, and I could easily expand. We could really user your help, especially as our small core team is not familiar with many of the other mentioned technologies: even if you don't feel like coding but are in the mood for bleeding edge testing that would be great.

Today is a big day. The first release of Hibernate OGM with final status. Ever! Don't be fooled by the 4.1 number. Hibernate OGM is an object mapper for various NoSQL stores and offers the familiar JPA APIs. This final version offers mapping for MongoDB, Neo4J, Infinispan and Ehcache.

It has been a long journey to reach this release, much longer than we thought. And there is a long journey ahead of us to implement our full (and exciting!) vision. But today is the time to celebrate: download this puppy and try it out.

What is Hibernate OGM?

Hibernate OGM is an object mapper. It persists object graphs into your NoSQL datastore.

We took great care to map the object structures the most natural way possible ; we considered all the best practices for each of the NoSQL store we support. Storing a association in a document store is vastly different than storing the same association in a graph database.

// Unidirectional one to many association

// Basket
{
  "_id" : "davide_basket",
  "owner" : "Davide",
  "products" : [ "Beer", "Pretzel" ]
}

// Products
{
  "_id" : "Pretzel",
  "description" : "Glutino Pretzel Sticks"
}
{
  "_id" : "Beer",
  "description" : "Tactical nuclear penguin"
}

Hibernate OGM is 90% Hibernate ORM. We changed the parts that are specific to SQL and JDBC, but most of the engine remains untouched. Same power, same flexibility.

What is the API like?

Very simple. It's JPA. Or Hibernate ORM. Map your entities with JPA annotations (or via XML), then use JPA or the Hibernate native APIs to manipulate your objects.

@PersistenceContext EntityManager em;

// the transaction boundary is really here to express the flush time
@Transactional
public void createSomeUser() {
    Employer redHat =
        em.createQuery("from Employer e where e.name = :name")
        .setParamater("name", "Red Hat")
        .getSingleResult();
    User emmanuel = new User("Emmanuel", "Bernard");
    user.setTwitterHandle("emmanuelbernard");
    user.setEmployer(redHat);
    em.persist(user);
}

Our goal is to have a zero barrier of entry to NoSQL object mappers for people familiar with JPA or Hibernate ORM.

Hibernate OGM also has a flexible option system that lets you customize some of the NoSQL store specifics or mapping options. For example what is the MongoDB Write Concern for this entity (see code example) or should associations be stored in the owning entity document.

@Entity
@WriteConcern(JOURNALED) // MongoDB write concern
public class User {
    ...
}

And queries?

We cannot talk about JPA without mentioning JP-QL. Offering JP-QL support is challenging at many levels. To mention only two, joins usually don't exist in NoSQL, and each store has a very different set of query capabilities.

Hibernate OGM can convert JP-QL queries to the underlying native query language of the datastore. This functionality is still limited however. Besides some queries will never map to JP-QL. So we also let you write native queries specific to your NoSQL store and map the results to managed entities.

// native query using CypherQL
String query = "MATCH ( n:Poem { name:'Portia', author:'Oscar Wilde' } ) RETURN n";
Poem poem = (Poem) em.createNativeQuery( query, Poem.class ).getSingleResult();

Where can I use Hibernate OGM?

It works anywhere Hibernate ORM or any JPA provider works. Java SE, Java EE, all should be good. We do require JPA 2.1 though. If you use WildFly (8.2), we have a dedicated module to make things even easier.

For which NoSQL store?

MongoDB, Neo4J, Infinispan and Ehcache are the one we consider stable. We are working on CouchDB and Cassandra. But really, any motivated person can try and map other NoSQL stores: that's how a few got started. We have an API that has proven flexible enough so far.

Can Hibernate OGM do X, Y, Z?

Probably. Maybe not.

The best is to talk to us in our forums, check our documentation (we spent a lot of time on it), and simply give it a try.

Generally, the mapping support is complete. Our query support is still a bit limited compared to where we want it to be. It will improve quickly now that the foundations are here.

We want to know what you need out of Hibernate OGM, what feature you miss, which one should be changed. Come and talk to us in our forum or anywhere you can find us.

How to get started?

Most of what you need is available in our web site. There is a getting started guide, and the more complete reference documentation. Get the full Hibernate OGM distribution. And last but not least, for any help, reach us via our forum.

It would be impossible to mention all the persons that contributed to Hibernate OGM and how: conversations, support, code, documentation, bootstrapping new datastore providers... Many thanks to all of you for making this a reality.

We are not done yet, far from it. We have plenty of ideas on where we want to bring Hibernate OGM. That's a discussion for another day.

Showing 6 to 10 of 1240 blog entries