Help

Inactive Bloggers

I am pleased to announce the release of Hibernate OGM 4.2.0.CR1.

The new version comes to you with initial support for Apache Cassandra, several improvements around JP-QL queries, support for MongoDB 3, MongoDB replica sets, new built-in types and much more.

You can download Hibernate OGM 4.2.0.CR1 from SourceForge or via Maven, Gradle etc., using the following GAV coordinates:

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

Preview for Apache Cassandra support

Cassandra is a highly performant and scalable datastore of the BigTable family. The request for supporting it dates back to the early days of Hibernate OGM. So it’s a great pleasure to finally have this puppy out. Many thanks to all that worked on this journey: Michaël Figuière, Khanh Maudoux, John Worrell and Jonathan Halliday!

To use the Cassandra backend, add the hibernate-ogm-cassandra module to your classpath and specify the following properties for your persistence unit:

hibernate.ogm.datastore.provider = cassandra_experimental
hibernate.ogm.datastore.database = my_keyspace
hibernate.ogm.datastore.host = cassandra.example.com

The Cassandra backend is in “tech preview” state at this moment. We still have lots of work left on our plates (e.g. clustering support, alternative association persistence options, queries, documentation), but we think we have the right foundation now. Be warned that mapping details still may change. Still this is the right time for you to give this new backend a first try and let us know about your experiences with it.

Any feature requests, error reports and other feedback are very welcome. Especially any thoughts on the proposed mapping of domain model elements to Cassandra structures are of great interest for us.

Query improvements

We spent some more time to improve support for mapping JP-QL queries either to native NoSQL queries or full-text queries executed via Hibernate Search + Lucene.

You can now use types like enums or Date as query parameters:

List<Movie> movies = entityManager.createQuery( "SELECT m FROM Movie m WHERE m.genre IN (:genre)", Movie.class )
    .setParameter( "genre", EnumSet.of( Genre.DRAMA, Genre.COMEDY ) )
    .getResultList();

As you would expect it, the given parameter values are converted into the corresponding type used in the datastore and passed to the query engine.

Mapping fix for element collections with nested embeddables

This release fixes a bug related to the mapping of nested embeddables stored within element collections. This affects the supported document stores as well as Neo4j. E.g. consider the following entity model:

@Entity
public class Account {

    @ElementCollection
    List<Address> addresses;
}

@Embeddable
public class Address {
    String street;
    String city;
    AddressType type;
}

@Embeddable
public class AddressType {
    String name;
}

Previously, this would have been stored as follows e.g. in MongoDB:

{
    "_id" : "account-1",
    "addresses" : [
        {
            "street" : "Piazza del Colosseo, 1",
            "city" : "Rome",
            "name" : "work" <-- “flattened” representation of the nested embeddable
        },
        ...
    ]
}

Whereas it really should be mapped like this:

{
    "_id" : "account-1",
    "addresses" : [
        {
            "street" : "Piazza del Colosseo, 1",
            "city" : "Rome",
            “type” : {
                "name" : "work"
            }
        },
        ...
    ]
}

This is the mapping applied as of this new release. Note that you need to take care of existing records should have been working with such a model. Also please check out the migration notes for the details.

We don’t take such mapping changes lightly and try to avoid them as much as we can. As this really was a mapping error, we decided to fix it as soon as possible; in the future we also may provide compatibility options or some sort of migration tooling in similar situations.

Support for MongoDB 3 and MongoDB replica sets

We now also support MongoDB 3. In particular the new SCRAM-SHA-1 authentication strategy is working now. Migration should be smooth.

But the biggest improvement is support for replica sets. To quote MongoDB’s documentation, a replica set “is a group of mongod processes that maintain the same data set”. By using replica sets, your data is stored redundantly and protected against node failures through automatic fail-over between replica set members.

To support the notion of replica sets, Hibernate OGM’s “host” configuration option has been enhanced and now allows to specify a comma-separated list of hosts and host:port tuples:

hibernate.ogm.datastore.host=db1.example.com,db2.example.com,db3.example.com:29019

With this configuration Hibernate OGM would connect to three MongoDB nodes, using the default port 27017 for the nodes db1 and db2 and the explicitly given port 29019 for node db3.

Currently the MongoDB backend is the only one supporting several nodes, but other backends will follow, e.g. Cassandra.

New built-in types for boolean mapping

Requested by a user in our forum, we now support all the boolean mapping types known from Hibernate ORM: YesNoType (maps to character/String “Y” or “N”), TrueFalseType (maps to “T” or “F”) and NumericBooleanType (maps to 1 or 0).

You can use these types by means of the @Type annotation like so:

// maps as boolean; default   
private boolean myBoolean;

@Type(type = "true_false")
private boolean myBoolean;

@Type(type = "yes_no")
private boolean myBoolean;

@Type(type = "numeric_boolean")
private boolean myBoolean;

Any feedback to the 4.2.0.CR1 release is highly welcome. The change log tells in detail what's in there for you. Finally, some more useful links:

15. May 2015, 05:22 CET, by Gail Badner

The primary reason for this release is to add support for running Hibernate ORM with Infinispan 7.2.1.Final as a runtime dependency. Hibernate still uses Infinispan 6.0.0.Final by default.

The plan is for WildFly 9 to include Hibernate ORM 4.3.10.Final. Since WildFly 9 uses Infinispan 7.2.1.Final, we had to make some corrections so that Hibernate ORM works properly with Infinispan 7.2.1.Final (as well as 6.0.0.Final) as a cache provider. To avoid backward-compatibility issues, Hibernate still uses an Infinispan 6.0.0.Final configuration by default.

In order to use Hibernate ORM with Infinispan 7.2.1.Final, it is necessary to specify an Infinispan 7.2 configuration using the environment variable, hibernate.cache.infinispan.cfg. An example of an Infinispan 7.2 configuration has been added as a test resource here.

For more information about changes to support Infinispan 7.2.1.Final, see: HHH-9776 and HHH-9781.

Other changes were minor. For more information, please see: https://hibernate.atlassian.net/jira/secure/ReleaseNote.jspa?projectId=10031&version=19650

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.10.Final Downloads: 4.3.10.Final ZIP, 4.3.10.Final TGZ

Following on the heels of 5.2.0.Final, Hibernate Search 5.3.0.Beta1 is now out. This time the faceting engine got an overhaul.

This work was long overdue, because there were several shortcomings with the existing implementation. For example, there were limitations with *ToMany associations. Also, the implementation was based on a custom Lucene Collector making use of the FieldCache API. FieldCache will be removed in Lucene 5, so updating the faceting API was also a requirement for upgrading to Lucene 5 in the near future.

What has changed? Actually not much when it comes to the API Hibernate Search exposes. You still create your FacetingRequest using QueryBuilder.facet().... You then enable the facet search by passing it to the FacetManager from which you also then retrieve the list of Facet instances after the query was executed. All this is unchanged and documented in the online documentation.

A few things have changed though. Most notably, you will need to tell Hibernate Search now which properties are used for faceting. You do so by adding @Facet (resp. @Facets) to these properties. The reason for this is, that under the hood the implementation is now based on Lucene's dynamic faceting capabilties. For this to work, we need to index the facet values using the appropriate DocValues type (SortedSetDocValuesFacetField, NumericDocValuesField or DoubleDocValuesField). Below we see the use of the @Facet(s) annotation:

    @Indexed
    public class Quux {
        @DocumentId
        private Integer id;
        
        @Field(analyze = Analyze.NO),
        @Facets({
                @Facet,
                @Facet(name = "string_facet_value", encoding = FacetEncodingType.STRING)
        })
        private double value;
    }
Notice that in this example the value field is configured with two facet annotations. The reason is, that per default numbers will be stored using numeric DocValues types (NumericDocValuesField and DoubleDocValuesField), whereas all other types use string based SortedSetDocValuesFacetField. Numeric values can then only be used with a range facet whereas discrete facets require string values. In the case where you want to use discrete faceting on a numeric field (for example if the field only contains a fixed number of possible values) FacetEncodingType.STRING needs to be used.

This is inline with the fact that Hibernate Search 5.x indexes numbers now per default numerically (see this blog).

A final caveat - there was a change in the default behaviour of includeZeroCounts as part of a facet request. The default was to include zero counts, but has changed now to not include it. Instead it must be explicitly specified (calculating zero counts for discrete facets comes with a performance penalty!):

    FacetingRequest request = queryBuilder( Car.class ).facet()
            .name( "quuxFacetRequest" )
            .onField( "string_facet_value" )
            .discrete()
            .includeZeroCounts( true )
            .createFacetingRequest();

Release info for Hibernate Search 5.3.0.Beta1

  • Full change log is available on JIRA
  • Artefact jars are available on Maven Central under the GAV org.hibernate:hibernate-search-orm:5.3.0.Beta1
  • Zip and tar bundles on SourceForge

Happy faceting!

The latest stable release of Hibernate Search, version 5.2.0.Final, is now available in Maven mirrors and as traditional downloads from Sourceforge.

Multi-tenancy integration

The most visible new feature is that it now transparently integrates with Hibernate ORM's support for multi-tenancy. The Hibernate Search documentation on multi-tenancy describes how using this near feature from Hibernate ORM will affect the content of your indexes and how it is transparently applied to any Query operation.

The good news is that, while you might want to read the documentation to better understand how it works exactly, the documentation is short as it's all pretty much automatic: full-text queries are automatically filtered on the tenant identifier, providing the same semantics as you would with any other kind of query.

Other improvements

This version incorporates many more improvements which we won't list in detail here. As usual you might find some benefits in the areas of performance and efficiency, improved javadocs, improved OSGi support. The Query builder DSL is improving thanks to the ever increasing great feedback. Keep it coming, we'll keep improving!

A reminder on the requirements for this version

  • Java 7 or later
  • Hibernate versions 4.3.x
  • Apache Lucene versions 4.10.x

What's coming next?

We've been working on a fully renewed Faceting support. Version 5.3.0.Beta1 will be available very soon as well, and include all of this work. Brace yourself though! While it will be API compatible, it will require some changes to your mapping: watch this space.

Get the update!

Everything you need is available on Hibernate Search's web site. Download the full distribution from here, or get it from Maven Central, and don't hesitate to reach us in our forums.

30. Apr 2015, 06:28 CET, by Steve Ebersole

I have just finished releasing Hibernate O/RM 5.0.0.Beta2. Beyond Beta1, this release adds:

  1. Support for Spatial/GIS data through importing Hibernate Spatial.
  2. Complete redesign of bulk id tables used to support update/delete queries against multi-table structures. The redesign helps better fit what different databases support.
  3. Redesign of transaction management
  4. Much improved (and still improving!) schema management tooling for export, validation and migration.

At this point, 5.0.0 is getting a lot of testing. So even though it is still in Beta I am feeling pretty confident of its quality. I opted for another Beta here instead of CR1 for a few reasons:

  1. Investigate whether we want to convert Hibernate's native APIs (Session, etc) to be typed. There is one especially tricky case that needs to be figured out. A major release like this would be the time to do that
  2. I have just introduced some pretty significant Transaction changes since Beta1. I felt it would be prudent to have one more Beta to allow people time to try out those changes and allow for additional changes based on feedback
  3. I would still like to complete deprecating the Settings contract. The last piece there is the discussion I started earlier on the dev list wrt its usage in SPI contracts (L2 cache, etc). This effects a few integrations.
  4. I am working on better Karaf support for hibernate-osgi. Specifically creating a Karaf features respository that users can simply pick up and use. That work is well under way, but ongoing.

As always, see http://hibernate.org/orm/downloads/ for information on obtaining Hibernate O/RM.

Showing 1 to 5 of 1254 blog entries