Help

Inactive Bloggers

It’s my great pleasure to announce the release of Hibernate OGM 4.1.0.Beta7! The release brings support for MongoDB’s object id, a clarification of what are our public API/SPI packages as well as several bugfixes and many other improvements.

Use the following GAV coordinates with tools such as Maven, Gradle etc.:

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

Alternatively, there is a release bundle containing Hibernate OGM and all its dependencies available for download from SourceForge.

Support for MongoDB’s object id

When talking about Hibernate OGM, one of the most requested features we heard was support for the native object id type in MongoDB. Finally we got around to implementing this feature.

You can map object ids either directly via MongoDB’s org.bson.types.ObjectId type or using a String. The following shows an example:

@Entity
public class GolfPlayer {

	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Type(type = "objectid")
	private String id;

	// Alternatively, the following could be used:
	// @Id
	// @GeneratedValue(strategy = GenerationType.IDENTITY)
	// private ObjectId id;

	private String name;

	private double handicap;

	//...
}

The @GeneratedValue annotation causes the id to be automatically generated by MongoDB upon insertion of the entity, similar to e.g. AUTO_INCREMENT columns in MySQL. The @Type annotation makes sure the string is mapped as an object id rather than as plain string. So a GolfPlayer document could e.g. look like this:

{
    "_id" : ObjectId("542ac33630043ffe5bcb4efa"),
    "name" : "Alexis",
    "handicap" : 9.7
}

Also related to MongoDB is a nice improvement around JP-QL queries. You can now refer to properties of embeddable objects in your queries:

@Entity
@NamedQuery(name = “PersonsByCity”, query = "FROM Person p WHERE p.address.city = :pCity")
public class Person {

	@Id
	private ObjectId id;

	@Embedded
	private Address address;

	// ...
}

Here, the named query refers to the city property of the embedded address object.

API/SPI package restructuring

As we’re on our road to the 4.1.0.Final release, we spent a fair amount of time for clearly separating the OGM code base into API, SPI and internal packages. Our goal is to make clear what is supported in the long term and what is not.

API packages (application programming interface) are all those packages which are intended to be accessed by users of Hibernate OGM, i.e. people building applications on top of it. Any package which does not have “spi” or “impl” in its name is an API package. Note that there are only very few API packages in Hibernate OGM. Most of the time you will work with the JPA (javax.persistence.* packages) or the “classic” API from Hibernate ORM.

SPI packages (service provider interface) are packages which contain contracts to be used and/or implemented by authors of custom grid dialects. So if for instance you would write a dialect for your favorite NoSQL store (btw. you should consider to contribute it to OGM), then you would access the SPI packages. They have a “spi” in their name. In order to clearly separate API and SPI, we had to rename several packages and move some types around. So existing custom dialects need to be adapted to this new structure. Good news is that it basically is enough to do a “re-organize imports” in your favorite IDE to adapt to most of the changes. We aim at a stable SPI (and of course API as well) with the 4.1 Final release.

Finally, there are internal packages of the Hibernate OGM engine which are not intended for usage by users nor dialect implementors. You can recognize those by the “impl” in their name. Internal packages and types may be changed, removed etc. without notice. So if you think there is a specific internal type which you need to access, please let us know so we can decide what to do and e.g. promote it to API or SPI.

Please refer to the migration notes to learn more about the package changes in this release.

Useful links

As always we’re very interested in your feedback. Here are some helpful links for you:

So give it a try and let us know how you like this release!

In a yet unforseen pace we have a new episode for you.

In #36 we are talking with Randall Hauch and Horia Chiorean about the ModeShape project.

As always find it all in the Show notes and episode.

Have fun!

This time around we are talking with David Jorm and Arun B. Neelicattu about Security, especially around Java.

We get to hear about how climate change helped improve JBoss, all about the secret societies surrounding security and how all software is basically doomed - but also learn how you can improve security for your framework(s) and application(s).

Listen in if you care about security and want to learn more, but also if you don't think you care - you might learn a few things. I know I did. Show notes and episode

Have fun!

Back from holidays, before we resume the work on Hibernate Search 5 for those of you maintaining a mature project we released today a micro bugfix release: 4.4.4.Final

Which version should I use?

Branch 4.4 is our Hibernate Search line for those using Hibernate 4.2.x aka JPA 2.0. If you're using Hibernate ORM at version higher than 4.3.0 then you want our JPA 2.1 compatible version - as included in WildFly 8.1 : Hibernate Search 4.5.x

For those starting new projects, wishing to help testing, or just interested in all the new power offered by Apache Lucene 4, you should try out our latest development version Hibernate Search 5.0.0.Alpha6

JBoss EAP users and customers

So this version 4.4.4.Final is compatible with the JBoss EAP 6.x line, but remember! If you have a JBoss EAP subscription you have access to the custom built version of Hibernate Search (included for free in the EAP subscription) which entitles you to premium support and more.

If you're using Hibernate Search via this subscription, I would LOVE you could drop me a line, even confidentially if you need so: by giving it away for free we're unable to track its usage and I need some data to justify team expansion options, so this could significantly help improve your free software.

What's new

Just one but important fix: a conconcurrency issue which you could hit if you're having high load while performing write operations out of transactions. If you recognize a pattern you might be using, you want to upgrade to avoid missing some index updates.

Special thanks to Yoann Gendre for identifying the problem and providing a test for it!

The Hibernate team is very happy to announce the release of another Beta of Hibernate OGM 4.1!

Progress has been made with respect to query execution and the Neo4j dialect. Also we do provide a so-called Bill of Materials POM now which the Maven users out there will appreciate (details below).

The GAV coordinates to be used with Maven, Gradle etc. are:

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

Alternatively you can fetch a release bundle containing Hibernate OGM and all its dependencies from SourceForge.

Please note that this new release requires Hibernate ORM 4.3.6.Final or later.

Query improvements

We've reworked major parts of the integration with the query execution machinery from ORM. This enables quite a few improvements in the field of JP-QL as well as native queries.

One is support for polymorphic queries also on those backends which don't use Hibernate Search for querying (Neo4j and MongoDB). This means queries targetting a super-class will return instances of any mapped sub-class as well.

Furthermore, Hibernate OGM now shows the same behavior with respect to auto-flushing you already know from Hibernate ORM. That is, if you submit a query, all pending changes to entities of the effected types will be flushed to the data store in order to ensure queries don't return any stale data. Whereas this works nicely on stores supporting full transaction semantics (namely, Neo4j), some care must be taken on stores with limited or non-existing rollback capabilities. Refer to the reference guide to learn more about the details.

In addition we took measures to cache native queries derived from JP-QL queries. Note that this requires Hibernate ORM 4.3.6.Final or newer. Generally we strive for compatibility with a complete minor release family (4.3.x), but in this case we need to make use of some advanced SPIs only introduced in 4.3.6. The module ZIP we provide for WildFly contains an updated ORM module as well. This will be added along side the existing ORM module, which remains unchanged.

More natural association mappings in Neo4j

As part of our ongoing work on the Neo4j dialect, associations are mapped to relationships finally the way you'd expect it. There used to be redundant properties on associations which are gone now. Only actual association properties are stored on relationships, e.g. the order of the elements of an ordered list. The following shows an example:

Here we have an entity Father with an ordered collection of Child entities which is mapped by a relationship to each Child node. The birthorder attribute (the name has been given via @OrderColumn) is stored as property on the relationships, just as it naturally makes sense.

On a tangent, we've updated to Neo4j 2.1.3.

Simplified version management

Another big usage improvement for Maven users comes in form of our new Bill of Material POM (BOM). This POM defines a set of matching versions of the Hibernate OGM modules and their dependencies, such as Hibernate ORM, Hibernate Search or the different datatstore connectors.

All you need to do is to add this BOM to the dependencyManagement block of your project POM using the special import scope:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.hibernate.ogm</groupId>
            <artifactId>hibernate-ogm-bom</artifactId>
            <version>4.1.0.Beta6</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Then you can declare dependencies to Hibernate OGM or any of the related modules without specifying a version, which you will get automatically from the BOM:

<dependencies>
    <dependency>
        <groupId>org.hibernate.ogm</groupId>
        <artifactId>hibernate-ogm-mongodb</artifactId>
    </dependency>
    <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-search-orm</artifactId>
    </dependency>
    <dependency>
        <groupId>org.hibernate.javax.persistence</groupId>
        <artifactId>hibernate-jpa-2.1-api</artifactId>
    </dependency>
    ...
</dependencies>

To update to a new version of Hibernate OGM, simply update the referenced version of the BOM. This in turn will give you updated versions of any dependencies as required.

Your feedback matters

As we're approaching the Final release of Hibernate OGM 4.1 soon, your feedback matters more than ever! You can use the following tools to get in touch:

Showing 1 to 5 of 1219 blog entries