Help

Inactive Bloggers
28. May 2015, 03:05 CET, by Steve Ebersole

The Hibernate team is proud to announce the first candidate release for 5.0. The main changes since the Beta2 release include:

  • Initial generic typing for Hibernate native (Session, e.g.) APIs
  • Continued development of the new bytecode enhancement capabilities including improved support in the Maven and Gradle plugins
  • Support for parameterized types with AttributeConverter implementations
  • Improved OSGi integration testing using Pax Exam and Karaf, and publishing a hibernate-osgi Karaf features file
  • Auto quoting of keywords used as identifiers (User, e.g.).
  • Incorporating fixes, improvements and suggestions to the improved schema update and validation tooling

A lot of help from the community went into this release and the previous Beta releases. Thanks for all the help and work and testing and doggedness!

As always, see http://hibernate.org/orm/downloads/ for information on obtaining the releases.

Report any issues to Hibernate Jira

Moving along towards a 5.2 Final, we are happy to announce the release of Hibernate Validator 5.2.0.CR1. The main goal of this release was to fix bugs and polish some of the new features. For example, we reviewed the Optional validation support and made sure its behavior is (what we think) consistent in all cases. You can find the full change log on JIRA.

Despite the focus on bug fixes, we still managed to sneak in a couple of new features. Hibernate Validator offers now a TimeProvider contract, as well as an extension of the Path API which allows to obtain the value of the represented property. Refer to the online documentation for more information.

Another more general question, which created quite a bit of discussion, revolved around the validation of Java 8 date/time types (JSR 310) (see HV-874). The question is, whether we can/should provide default ConstraintValidator implementations for @Past and @Future validating LocalDate (or any of the other date/time types which do not represent a instant in time). The Javadocs tells us:

This class does not store or represent a time or time-zone. Instead, it is a description of the date, as used for birthdays. It cannot represent an instant on the time-line without additional information such as an offset or time-zone.

Without a instant in time, however, past and future are undefined. One can only validate such an instant by associating a timezone with it. But which one? The time zone of the current JVM? That could lead to unexpected behavior for example in client-server applications. If you have an opinion on this or an idea on how to solve this, please leave a comment or use any of the other means listed below to get into touch with us. We would love to hear from you. For now, Hibernate Validator will not support LocalDate out of the box. We will see how this pans out.

Where do I get the release?

Maven artifacts can be found in the JBoss Maven repository (GAV org.hibernate:hibernate-validator:5.2.0.CR1) and will within a short time also be synced to Maven Central. Distribution bundles are as usual available on SourceForge.

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.

Enjoy!

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!

Showing 1 to 5 of 1256 blog entries