Help

Inactive Bloggers
26. Jun 2014, 08:19 CET, by Gail Badner

Hibernate ORM 4.2.14.Final was just released! Please see the full changelog for more information: https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=17152.

Another 4.2.x version was necessary to make the following changes:

  • HHH-9255 reverts HHH-9222, which caused incorrect SQL to be generated when bulk deleting collections that use a property-ref;
  • HHH-9252 fixes a bug where an error executing a batch did not abort the rest of the batch.

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

This post is about validation, Bean Validation specifically. And the what it solves. It is a reaction to a post by Julien Tournay which basically claims - if I sum it up - that:

  • Scala is faster than Java (he is coming from far far away on that one - du diable vauvert as we say in French)
  • Bean Validation is kind of crap
  • The new Play Unified Validation API is awesome

I usually am old and wise enough not to answer these kind of posts. But I want to feel the blood of my youth again damn it! After all I am from an era when The Server Side was all the rage, trolls had real teeth, things were black or white. That was good fun.

Why the You missed the point like Mars Climate Orbiter title? With a sensationalist title like Scala is faster than Java, I had to step up my game. Plus Mars Climate Orbiter missed Mars due to a conversion error and we will talk about conversion today.

I won't refute things point by point but rather highlight a few fundamental misunderstandings and explain why things are like they are in Bean Validation and why it makes sense.

Java was limiting

IMHO, @emmanuelbernard a créer son API avec les outils a sa disposition - @skaalf
IMHO, @emmanuelbernard has created his API with the tools he had at his disposal - @skaalf

We certainly pushed the boundaries of Java when both CDI and Bean Validation were designed and I wished I had more freedom here and there. But no Bean Validation is like it is because that's the most natural way validation is expressed in the Java ecosystem for what we wanted to achieve. It is no good to offer something that does not fit into the ecosystem.

For example, in Java, people use mutable objects. Mutable believe it or not is not a swear word in this language. My understanding is that Play Unified Validation API makes use of Scala's community incline for immutability.

Validation, conversion and marshalling

In the use case Julien takes as an example, a JSON string is unmarshalled, conversion is applied (for dates - darn JSON) and then values are validated. He considers it weird that Bean Validation only does the latter and finds the flow wrong.

We kept this separation on purpose. The expert group vastly agreed that Bean Validation was not in the business of conversion and that these steps ((un)marshalling, conversion, validation) should be separated. Here is a key reason:

  • marshalling and conversions are only at the Java boundaries (Web frameworks, services enpoints, datastores enpoints, etc)
  • validation happens both at these boundaries but also at key lifecycle events within the Java boundaries

Conceptually, separating validation from the rest makes a lot of sense to enable technology composition and avoid repetitions - more on that latter point later. What is important is that for a given boundary, they are properly integrated. It's not unlike inlining in compilation.

Bean Validation is in the business of not being called

One key point in the design of Bean Validation is that it has been built to be integrated within a cohesive stack more than to be used individually.

JPA transparently calls Bean Validation on your objects at the right time. JSF calls Bean Validation transparently before populating the beans. JAX-RS calls Bean Validation on the inbound and outbound resources transparently. Note that these three technologies do address the marshalling and conversion problem already. That's their job.

So the key is that an application rarely has to call the Bean Validation API. I consider it a failure or an unfinished work when it has to.

If you need to explicitly validate some piece of data in a fire and forget way, Bean Validation might not be the best tool. And that's OK.

Back to the JSON case. When the JSON Binding spec will be out, we will have the same integration that is currently present in Play Unified parsing, conversion and validation API (it could also be done today in Jackson, I'm not sure what extension points this library offers). While the three layers marshalling / conversion / validation will be conceptually separated - and I'm sure will report different types of error for better tracking - the implementation will use some specific APIs of Bean Validation to inline validation with the unmarshalling and conversion. That API exists BTW, it is Validator.validateValue which lets you validate a value without creating the POJO associated. It is used by web frameworks already. Pretty much what Play Unified Validation API does.

As for JAX-B and XML binding, well let's say that there is an X in it and that it's not safe for children. More seriously, we have integration plans with mapping between the XSD and the Bean Validation constraints but we haven't got around to do it yet.

Bean Validation is in the business of declaring constraints once

From what I see of the Play Unified Validation API, you put the declaration / implementation of the validation next the marshalling logic. In other words you cannot share the constraint declaration between different marshalling operations or even between object transformations.

Bean Validation has been designed to let the user declare the constraints once and have them validated across the whole stack. From the web form and service entry points down to the database input/output and schema definition. Some even use our metadata facility to propagate the constraints up to the client side (JavaScript).

And that's future proof, when we add JSON-B support, boom the constraints already declared are used automatically and for free.

Conclusion

Bean Validation cannot be understood if you take it in isolation. It is useful and works in isolation for sure but it shines when integrated in a platform from top to bottom. We did and keep doing it in Java EE but we also make sure to keep our APIs and SPIs open for other platforms to do the same. Spring famously has been doing some of it.

Let's mention a few key features of Bean Validation that are not addressed at all in Play's approach:

  • i18n
  • constraint inheritance
  • method validation
  • custom and context sensitive programmatic error report
  • partially valid object graph - yes that's important in a mutable world
  • etc

Even a few of these would make Play's stuff much much different.

Now with this context properly set, if you read back Julien's complaints about Bean Validation (especially about they design), they fall one by one pretty much. I have to admit their composition approach is much nicer than Bean Validation's which relies on annotated annotations. That's the main thing I miss.

Design is choice. Without knowledge to the designer's choices, you can too easily misunderstand her design and motives. Julien has been comparing Apples with Oranges, which is ironic for someone working on one of the most type-safe language out there :o)

But it's good that more people take data validation holistically and seriously and step up the game. Less work for app developers, safer apps, happier customers. Judging by the location, I could even share some thoughts over a few rounds of whisky with Julien :)

Peace.

I'm happy to announce a new release of Hibernate OGM.

The MongoDB backend now supports the MongoDB CLI syntax for native queries. In Neo4j, we have solved a bug related to the way we store embedded collections (OGM-549) and we now create only one relationship for bidirectional associations. We have also worked on the compatibility with WildFLy 8.1. You can find more details about this release on JIRA.

As always, you can either download a release bundle from SourceForge or retrieve the JARs from the JBoss Nexus repository server using Maven, Gradle etc. The GAV coordinates are:

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

Support for MongoDB CLI syntax

You can now specify queries using the MongoDB CLI syntax as shown in the following example:

    @Entity
    class Poem {
       ...
       String name;
       String author;
       ...
    }

    String poemsQuery = "db.Poem.find({'$query': { 'author': 'Oscar Wilde' }, '$orderby': { 'name': 1 }})";

    EntityManager em = ...
    List<Poem> oscarWildePoems = (List<Poem>)em.createNativeQuery( poemsQuery, Poem.class )
                                 .getResultList();

Currently only find() and count() queries are supported via the CLI syntax.

One relationship for bidirectional associations

In Neo4j, it is possible to navigate a relationship in both directions at the same speed. We moved to a more natural mapping using one relationship (instead of two) for a bidirectional association.

What's next?

For the Neo4j backend, we plan to make the mapping for one-to-one relationships more natural, remove redundant properties and translate JP-QL queries into native Cypher queries.

We will also work on the generation of error reports with the failed operations on non-transactional db.

You're very welcome to raise your voice on the mailing list, ask questions in the forum or report any bugs or feature requests in the issue tracker.

29. May 2014, 22:44 CET, by Gail Badner

Hibernate ORM 4.2.13.Final was just released! Please see the full changelog for more information: https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=16650.

Another 4.2.x release was necessary to fix the following:

  • HHH-9154: fixes a regression introduced in 4.2.12 that broke HQL queries with a named parameter that is an HQL keyword;
  • HHH-9204: fixes a regression introduced in 4.2.12 that changed the method signature for an SPI, AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection, Serializable, SessionImplementor);
  • HHH-9170: fixes a regression introduced in 4.2.8 that enables the second-level cache for a StatelessSession in some cases.

In addition, there were several improvements and minor fixes.

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

Showing 6 to 10 of 1213 blog entries