Red Hat

In Relation To Hibernate Search

In Relation To Hibernate Search

Simple Query String, what about it?

Posted by    |       |    Tagged as Hibernate Search

In the last Hibernate Search release announcement, you might have noticed something about Simple Query Strings.

The documentation is still a little sparse and we wanted to give this feature some more light and have some feedback before going Final with it.

This feature is part of the already released 5.8.0.Beta1 so you can already play with it (either with the Lucene backend or with the new Elasticsearch backend).

What’s a Simple Query String?

Let’s begin with some history.

Lucene 4.7.0 introduced a new query parser, the SimpleQueryParser, presented as a "parser for human-entered queries". The point of this parser is to be a very simple lenient state machine to parse queries entered by your end users.

The parser is capable to transform keyword "some phrase" -keywordidontwant fuzzy~ prefix* into a Lucene query, giving your users a little more power (phrase queries, fuzzy queries, boolean operators…​). The lenient part is important as it will try to build the best possible query without throwing a parse exception, even if the query is not what we would consider syntactically correct.

Another nice feature is that it allows to search on multiple fields. You basically end up establishing the following contract with Lucene:

  • users will enter a search query (more or less syntactically correct)

  • it will search on the fields you have specified (and you can also specify a specific boost for each field)

  • you can enable each of the features that you want to expose to the users (i.e. you can enable the phrase queries but not the boolean operators)

  • building the query won’t throw an exception

So, what is a Simple Query String for us? Just a string following the SimpleQueryParser syntax or, in user terms, what the user entered in the search box.

Let’s take an example

In the following, we will base our discussion on the following Book entity:

@Entity
@Indexed
public class Book {

    // [...]

    @Field
    private String title;

    @Field
    private String summary;

    @Field
    private String author;

    // [...]
}

Our goal is to be able to search war peace on the title field with a boost of 5 and on the summary field with a boost of 2 and have only the results containing both words. A Book containing war in title and peace in summary should be considered a valid result.

Until now, to fulfill these requirements with Hibernate Search, you had the following possibilities:

Use the DSL
  • Manually split the search query into keywords

  • Manually build a (rather complicated) query using the keyword() entry point of the DSL (keyword() only supports OR so you would have to build several different keyword() queries for each keyword and for each field)

  • Downsides:

    • it is not possible to allow the users to optionally enter phrase queries, fuzzy queries…​ without implementing a parser (or having checkbox options to enable them)

    • it might lead to a lot of boilerplate code if you want to search in more than 2 fields

Use the Lucene MultiFieldQueryParser
  • Quite efficient

  • Downsides:

    • Not lenient: can throw a ParseException

    • You expose the full power of the Lucene default QueryParser which might not be what you want

    • You can define the default fields but the user can search on other fields with the field:keyword syntax: it might not be what you want

How would we do it with the new simpleQueryString() DSL entry point?

It is as simple as:

String simpleQueryString = "war peace"; // what the end user is looking for

QueryBuilder qb = fullTextSession.getSearchFactory()
            .buildQueryBuilder()
            .forEntity( Book.class)
            .get(); // instantiate the QueryBuilder providing the DSL

Query query = qb.simpleQueryString()
            .onField( "title" ).boostedTo( 5.0f )
            .andField( "summary" ).boostedTo( 2.0f )
            .withAndAsDefaultOperator() // we want AND to be the default operator
            .matching( simpleQueryString )
            .createQuery();
List<Book> results = fullTextSession.createFullTextQuery( query, Book.class ).getResultList();

Important precision: the default operator used if you don’t define the operator explicitly is OR. In the general case, it might not be what you’re looking for, thus the call to withAndAsDefaultOperator() in the example above.

If you also want to search on the author field, just add another andField() clause and you’re done.

The thing I particularly like about it is the fact that you’re able to define a simple contract with your Lucene index and that the users have some flexibility to define more advanced queries inside the contract you defined:

  • -war peace: documents contain peace but not war

  • war | peace: documents contain war or peace (you can omit the | operator if it is defined as the default)

  • war + pea*: documents contain war and at least a word starting with pea (you can omit the + operator if it is defined as the default)

  • "war and peace": documents contain the phrase war and peace

  • pease~: documents contain pease with a fuzzy search so documents containing peace will be returned too

  • war + (peace | harmony): documents contain war and either peace or harmony

  • and any combinations of the above…​

  • or none: simple searches are obviously also supported!

What do you think about it?

Still there? We have a few questions for you.

First, after a lot of discussions, we have chosen to name the DSL entry point simpleQueryString(). It has the advantage to be consistent with Elasticsearch. If you can think of a better (and maybe more explicit) name, it’s not too late to join the party! Once we go final, we will stick to this name foreeeever.

Your feedback is very welcome in the comments below or on the hibernate-dev mailing list.

Secondly, for now, we haven’t exposed the ability to disable particular features. By default, the following features are all enabled:

  • boolean operators (+, - and |)

  • precedence operators (parenthesis)

  • phrase search ("some phrase")

  • prefix operator (prefix*)

  • fuzzy operator (fuzzy~)

  • slop for phrase search ("some phrase"~2)

Think it might be useful to be able to disable features? Feel free to open an issue on our JIRA or even better propose a pull request! You can find the original patch here: https://github.com/hibernate/hibernate-search/pull/1318, it might help you to start.

Just a quick heads-up to French-speaking developers: I will be presenting the Elasticsearch integration in Hibernate Search at the Strasbourg Java User Group (ElsassJUG) meetup, at 7 PM on Wednesday 26th of April.

I will briefly introduce full-text search (why and how it’s done), then present how to use Hibernate Search to keep Lucene indexes in sync with your Hibernate ORM entities, and I will show you how easy it is to target Elasticsearch instead of local Lucene indexes since Hibernate Search 5.6.0.

For more information about the location or to register, please refer to the Meetup page.

We just published Hibernate Search version 5.8.0.Beta1, which is now compatible with Elasticsearch versions 5.x.

New improved Elasticsearch client

This release now uses the new Elasticsearch REST client, which is expected to be a safe choice in terms of long term maintenance as it’s sponsored and recommended by the Elasticsearch team.

Compared to the driver we used previously, this one uses a state of the art reactive architecture, so we can take advantage of more efficient resource utilization.

Elasticsearch 2.x is still supported

The new driver is backwards compatible, so we’ll still be able to connect to clusters running Elasticsearch 2.x.

This doesn’t need any configuration flag as Hibernate Search can automatically detect the version of Elasticsearch it’s being pointed to.

The features supported by Elasticsearch 5.x and 2.x are however slightly different and you’ll find that some low level mapping features are documented as compatible with only one specific version.

The migration guide will be updated when this minor release will be feature complete.

New Simple Query String supported by the Query builder DSL

The useful capabilities from Lucene’s SimpleQueryParser are now conveniently exposed by our higher level DSL.

We’ll publish a detailed blog about this new feature soon: stay tuned!

If you can’t wait, we won’t prevent you from peeking into the Simple Query String documentation.

Simplified JNDI configuration

If you integrated any external component into Hibernate Search using JNDI, for example a JMS queue or an Infinispan cache, this configuration was simplified.

You will no longer need to set Hibernate Search specific configuration properties such as how to set the InitialContext for JNDI lookups: only configure Hibernate ORM, and Hibernate Search will inherit the same settings.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.8.0.Beta1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.8.0.Beta1</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback

Feedback always welcome!

Please let us know of any problem or suggestion by creating an issue on JIRA, or by sending an email to the developer’s developer’s mailing lists, or posting on the forums.

We also monitor Stack Overflow; when posting on SO please use the tag hibernate-search.

Eclipse tools for Hibernate Search

Posted by    |       |    Tagged as Hibernate Search JBoss Tools

I’m glad to announce the second release of the Eclipse plugin for Hibernate Search. In this post I’m describing the changes and new features of the release. Here you can find the first release blog post.

Index Toolkit

The major change of the release is that all functionality, except "Index Rebuild", are now grouped in the Index Toolkit view. To open it, right-click on a configuration in the Hibernate Configurations view and choose "Open Index Toolkit".

Configuration menu items

Here you can find three tabs: Analyzers, Explore Documents, Search. The first two tabs repeat functionality from the first release of the plugin.

Analyzers Toolkit tab
Explore Documents tab

Searching

The new feature of the release is the capability to easily execute the search.

Search tab

The plugin passes the input string from the search text box to the QueryParser which parses it using the specified analyzer and creates a set of search terms, one term per token, over the specified default field. The result of the search pulls back all documents which contain the terms and lists them in a table below.

Demo

What’s next

The next step is to merge this plugin with the JBoss Tools Hibernate plugin. Currently, the Hibernate Search plugin is based on the Hibernate plugin which must be installed beforehand to prevent a "missing required feature" error.

You asked for it, we deliver: Hibernate Search 5.7.0.Final, with support for Hibernate ORM 5.2.8, is out! And of course, like previous versions, it features experimental support for Elasticsearch integration (even with some improvements).

Stuck on an older ORM version? Don’t worry, we also released a bugfix version for 5.6, namely 5.6.1.Final.

Hibernate Search 5.7.0.Final is only compatible with Hibernate ORM 5.2.3 and later. There isn’t any version of Hibernate Search compatible Hibernate ORM 5.2.0 to 5.2.2.

If you need to use Hibernate ORM 5.0.x or 5.1.x and cannot upgrade, please use Hibernate Search 5.6.1.Final.

What’s new on 5.7 since the candidate release?

Below are the main changes since the candidate release.

If you are looking for advice on how to migrate, please refer to the migration guide.

For a full list of changes since 5.7.0.CR1, please see the release notes. For a full list of changes since 5.6.0.Final, please see this list of tickets on our JIRA instance.

General improvements

  • HSEARCH-2574: when it makes sense, you can now repeat Hibernate Search annotations on a single attribute/method. For example, if you want to add two index fields on the same title attribute, you can write:

        @Field(analyzer = @Analyzer(definition = "myAnalyzer")
        @Field(name = "title_sort", analyzer = @Analyzer(definition = "myAnalyzerForSort")
        private String title;

    Thus you don’t have to use the composite annotations (@Fields) anymore. But of course, those are still available.

  • HSEARCH-2588: some methods in the Sort DSL allowed to specify the sort field type explicitly, which was useful when sorting on fields added through custom field bridges. We improved support for MetadataProvidingFieldBridge, so that you now only need to implement this interface on your custom field bridges, and won’t need anything special when using the sort DSL anymore. As a result, the byField(String, SortField.Type) and andByField(String, SortField.Type) methods in the sort DSL have been deprecated.

  • HSEARCH-2587: an NPE could occur when using the Sort DSL to sort on embedded (@IndexedEmbedded) fields; this is now fixed.

  • HSEARCH-2576: unnecessary memory allocations within queries have been removed, resulting in better query throughput.

  • And several improvements for other solutions integrating Hibernate Search, like HSEARCH-2597, HSEARCH-2561, HSEARCH-2418 or HSEARCH-2585.

Elasticsearch-specific improvements

  • HSEARCH-2453: Elasticsearch authentication is now fully implemented: there are dedicated username and password properties so that you don’t need to embed the credentials in the URL anymore.

  • HSEARCH-2593: when using automatic node discovery on Elasticsearch, a scheme (HTTP or HTTPS) cannot be detected automatically for newly discovered nodes; by default it is HTTP. You can now customize this to use HTTPS instead: just add hibernate.search.default.elasticsearch.discovery.default_scheme https to your configuration.

  • HSEARCH-2590: queries using pagination could allocate too much memory in certain circumstances; this is now fixed.

What’s new on 5.6?

5.6.1.Final contains exclusively backported fixes from 5.7. You can see a full list of changes since 5.6.0.Final in the release notes.

What’s next?

We’re now focusing on the next two big improvements:

  • support for Elasticsearch 5 without losing support for Elasticsearch 2 (HSEARCH-2434, HSEARCH-2581). This will be in a 5.8 release.

  • streamlining our APIs, in particular to better fit remote indexing services (like Elasticsearch), but also to support Lucene 6. Due to the breaking changes this requires, we will include these changes in a new major release, Hibernate Search 6.0.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.Final</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.7.0.Final</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

After a relatively quiet candidate release, we just published Hibernate Search version 5.6.0.Final with experimental Elasticsearch integration, along with 5.7.0.CR1.

Version 5.6.0.Final brings the latest bugfixes for our experimental Elasticsearch integration. This is the version to use with Hibernate ORM versions 5.0 and 5.1.

Version 5.7.0.CR1 brings the exact same changes as 5.6.0.Final, and now features the compatibility with Hibernate ORM version 5.2.7 (but not lower than 5.2.3, see more on this further down).

What’s new on 5.6 since the candidate release?

Below are the main changes since the candidate release.

For a full list of changes since 5.6.0.CR1, please see the release notes. For a full list of changes since 5.5, please see this list of tickets on our JIRA instance.

Common changes

  • HSEARCH-2547: nesting an @IndexedEmbedded with includePaths within an @IndexedEmbedded without an includePaths will now work properly.

  • HSEARCH-2535: @Facet with string encoding will now work properly on multi-valued properties (such as String[] or List<String>).

Elasticsearch-specific changes

  • HSEARCH-2501: the handling of @CalendarBridge.resolution with Elasticsearch was aligned on the one with Lucene: they are now consistent.

  • HSEARCH-2531: with Elasticsearch, index names can now be overridden using configuration properties, just like when using Lucene. Thanks to Cary Yu for reporting the issue!

  • HSEARCH-2519 and HSEARCH-2520: the Elasticsearch VALIDATE and MERGE index management strategies now handle analyzer definitions. This will only affect you if you were using @AnalyzerDef-defined analyzers on entities that are indexed in Elasticsearch. If you are, please be aware that the MERGE strategy may now close/reopen your index automatically during bootstrap! See the reference documentation for more information about the MERGE strategy.

What’s new on 5.7?

The main change in 5.7.0.CR1 since 5.7.0.Beta2 is the upgrade to Hibernate ORM 5.2.7. For a full list of changes, see the release notes.

Please note that Hibernate Search 5.7 now requires Hibernate ORM 5.2.3 onwards, and cannot be used with previous Hibernate ORM versions.

When will 5.7 be released?

5.7 is beginning its candidate release period, meaning that as far as we are concerned, it is already ready. We are giving a last chance for the community to report bugs, and unless we are delayed by major bugs, the actual 5.7.0.Final release should happen in mid-February.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.6.0.Final</version>
</dependency>

Or, for Hibernate Search 5.7:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.CR1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.Final</version>
</dependency>

Change the version to 5.7.0.CR1 in order to test the Hibernate ORM 5.2 integration.

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Hibernate Search 5.5.6.Final is out

Posted by    |       |    Tagged as Hibernate Search Releases

Hibernate Search 5.5.6.Final is here!

This is a maintenance release and contains exclusively bugfixes.

What’s new?

  • HSEARCH-2494: @TikaBridge will now work correctly on properties of type byte[].

  • HSEARCH-2535: @Facet with string encoding will now work properly on multi-valued properties (such as String[] or List<String>).

  • HSEARCH-2486: @ContainedIn in a superclass will now be taken into account even if the concrete class does not carry any Hibernate Search annotation.

  • HSEARCH-2479: building phrase queries with the Hibernate Search DSL used to trigger an IllegalArgumentException in some specific cases; this has been fixed.

  • …​ and more: the full change log can be found on our JIRA instance.

Thanks to Julien Bénichou, Andrew Robie and Timo Tretter for reporting issues, and even fixing one!

How to get this release

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.5.6.Final</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

It’s finally here! We just published the first candidate release of Hibernate Search with experimental Elasticsearch integration (5.6.0.CR1), along with 5.7.0.Beta2.

Version 5.6.0.CR1 brings the latest bugfixes and previously missing features for our experimental Elasticsearch integration. This is the version to use with Hibernate ORM versions 5.0 and 5.1.

Version 5.7.0.Beta2 brings the exact same changes as 5.6.0.CR1, and it still features the compatibility with Hibernate ORM version 5.2 that was introduced with 5.7.0.Alpha1.

What’s new?

  • HSEARCH-2348: Elasticsearch queries are now logged at the DEBUG level on the org.hibernate.search.fulltext_query logger, just as embedded Lucene queries.

  • HSEARCH-2449: more configuration options have been added regarding the connection to Elasticsearch, including the size of connection pools, the connection/read timeouts, and the automatic discovery of new nodes in the Elasticsearch cluster for client-side loadbalancing and (limited) failover.

  • HSEARCH-2219: analyzer definitions are now automatically translated and added to the Elasticsearch settings when Elasticsearch indexes are created. Please note there are still some limitations, most notably the definitions are not updated automatically (no support for the MERGE schema management strategy). See the documentation for more information about analyzers with Elasticsearch.

  • HSEARCH-2387: Elasticsearch mappings generated by Hibernate Search used to be strictly static. This can be an issue in some cases, which is why opt-in dynamic mappings are now available, either through a global option (see org.hibernate.search.elasticsearch.cfg.ElasticsearchEnvironment.DYNAMIC_MAPPING) or locally on metadata-providing field bridges (builder.field( name, FieldType.OBJECT ).mappedOn( Elasticsearch.class ).dynamic( DynamicType.TRUE )). Thanks to Alex Laptseu for reporting this!

  • …​ and much more, mainly bug fixes. The full change log can be found on our JIRA instance.

When will 5.6 be released?

As far as we are concerned, 5.6 is ready. Version 5.6.0.CR1 is the last opportunity for the community to test it and report bugs before the release which, if all goes well, will happen in early January.

What about Elasticsearch 5 support?

As mentioned in the blog post about the previous release, Elasticsearch 5.x is not supported yet.

Quoting:

The main reason is it brings several backward-incompatible changes that would require quite a bit of work if we still want to support the 2.x series. And we don’t want to postpone the Hibernate Search 5.6.0 release any more.

Our plan is to release a 5.6 supporting Elasticsearch 2.x, and add Elasticsearch 5 support in Hibernate Search 6.0 or, maybe, in an early 5.8 release. You may refer to HSEARCH-2434 to track the status of Elasticsearch 5.0 support.

When will 5.7 be released?

We are planning to publish a candidate release for 5.7 soon after 5.6.0.Final has been released.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.6.0.CR1</version>
</dependency>

Or, for Hibernate Search 5.7:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.Beta2</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.CR1</version>
</dependency>

Change the version to 5.7.0.Beta2 in order to test the Elasticsearch integration within Hibernate Search 5.7.

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Today we are releasing two new versions of Hibernate Search: 5.6.0.Beta4 and 5.7.0.Beta1!

Version 5.6.0.Beta4 brings the latest bugfixes and previously missing features for our experimental Elasticsearch integration. This is the version to use with Hibernate ORM versions 5.0.x and 5.1.x.

Version 5.7.0.Beta1 brings the exact same changes as 5.6.0.Beta1, but on top of the compatibility with Hibernate ORM version 5.2.x that was introduced with 5.7.0.Alpha1.

What’s new?

  • HSEARCH-402: A new async reader strategy has been added for the Lucene indexing service, bringing performance boosts when you are okay with your queries being run on an out-of-date index (how much out-of-date is configurable).

  • HSEARCH-2260: A new VALIDATE index schema management strategy has been added for Elasticsearch, allowing you to automatically check on startup that your Hibernate Search mappings are in line with the Elasticsearch mappings.

  • Issues with @IndexedEmbedded in the Elasticsearch integration have be addressed: everything should now work properly, with the notable exception of @IndexedEmbedded.indexNullAs (not to be confused with @Field.indexNullAs).

  • HSEARCH-2235: You can now configure Hibernate Search to send requests to Elasticsearch servers in round-robin, enabling load-balancing. Failover is not supported yet, but we’ll be working on it.

  • HSEARCH-2360: Elasticsearch projections now use source filtering, greatly reducing the bandwidth needs when retrieving results.

  • We now test our Elasticsearch integration against version 2.4.2, which fixed an issue with date formats that impacted Hibernate Search. We strongly recommend to update your 2.4.x instances to the lastest available version in the 2.4.x series.

  • …​ and much more. The full change log can be found on our JIRA instance or on our GitHub repository.

When will this 5.6.0 be released?

We’ve been caught up in the polishing work with the Elasticsearch integration lately, but we’re seeing the end of the tunnel: the list of open tasks is getting shorter and shorter. The first release candidate for Hibernate Search 5.6.0 will land by the end of next week.

So, if you haven’t tested 5.6 already, now’s the time! Should you find any bug, please report them on our JIRA instance.

What about Elasticsearch 5 support?

Please be aware that we’re not currently supporting Elasticsearch 5.x. The main reason is it brings several backward-incompatible changes that would require quite a bit of work if we still want to support the 2.x series. And we don’t want to postpone the Hibernate Search 5.6.0 release any more.

Our plan is to release a 5.6.0 supporting Elasticsearch 2.x, and add Elasticsearch 5 support in Hibernate Search 6.0 or, maybe, in an early 5.8 release. You may refer to HSEARCH-2434 to track the status of Elasticsearch 5.0 support.

When will 5.7.0 be released?

Everything is going smoothly with this version, and very few bugs have been reported. As soon as 5.6.0 will be released, we’ll publish the candidate release for 5.7.0.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.6.0.Beta4</version>
</dependency>

Or, for Hibernate Search 5.7:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.Beta1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.Beta4</version>
</dependency>

(Change the version to 5.7.0.Beta1 in order to test the Elasticsearch integration within Hibernate Search 5.7)

Downloads from Sourceforge are available as well.

In this post, I’d like you to meet Michael Simons, a long-time Spring and Hibernate user, and NetBeans Dream Team member.

Michael Simons, align=
  1. Hi, Michael. Would you like to introduce yourself and tell us a little bit about your developer experience?

    My name is Michael Simons, @rotnroll666 on Twitter.

    I am a 37 year old developer living in Aachen, Germany. As such, I qualify at least age wise as a senior developer. I’ve been in the software industry for nearly 15 years now. I do have a technical apprenticeship and half finished degree in applied Mathematics. I never finished those studies as I landed in the company I still work with, ENERKO INFORMATIK.

    Apart from being a husband and a father of two, I run our local JUG, the Euregio JUG.

    I’m also a member of the NetBeans Dream Team.

    We, at ENERKO INFORMATIK, create software in the energy and utility markets and work both in the technical and geographical parts as well as sales.

    I did really database-centric software for at least 4 years and, I am still fluent in SQL and also PL/SQL. We once did XML processing inside Oracle databases, which works surprisingly well. After the slow death of Oracle Forms Client / Server, we migrated our desktop applications from 2004 onwards to Java Swing.

    Around that time I played around with Hibernate for the first time. It seemed like the golden bullet back then to get table rows into objects. It wasn’t. But that I learned much later. As Gavin King said: „Just because you’re using Hibernate, doesn’t mean you have to use it for everything.“

    Apart from „boring“ business application, I’ve been not only blogging for a long time but ran several online communities, one of them still alive. Daily Fratze is a daily photo project started in 2005 as a PHP application. Then, in 2006 became a Ruby on Rails site and by 2010, I started migrating it to a Spring and Hibernate backend.

    Looking back at that code I notice how much I didn’t know about the purpose and intention of JPA / Hibernate. As it is true for a lot of stuff, you have to know your tools and the stuff they are designed for. Not all relations are meant to be materialized in objects, not all queries can be generated. And knowledge about when a Session is flushed and when not is essential. It’s not enough to know SQL to fully utilize Hibernate, but it’s also not enough to know Hibernate for abstracting persistence away. I changed the flaws in the site code, but you as the reader of this interview must not learn it the hard way, I really recommend Vlad Mihalcea's book High-Performance Java Persistence.

    My biking project and the site and API of the Euregio JUG are my latest public projects that represent the stuff learned with the experience above. I use those projects as reference projects for my work.

    Since several years, I mostly use NetBeans exclusively for all kind of software development. It supports me for plain Java, Spring, insanely well for JPA entities (build in checks for queries, coding style), for front-end (HTML as well as JavaScript). Most important, it has great integration for code quality related tools like JaCoCo, Sonar and more.

  2. You’ve designed the Java User Group Euregio Maas-Rhine site. Can you tell us what frameworks have you used?

    For Euregio JUG (source is on GitHub), I chose the following:

    • Spring Boot as the application container and glue for

      • Spring Framework and MVC

      • JPA and its implementation Hibernate

      • Spring Data JPA

    • The frontend is done pretty old school by server side rendered templates using Thymeleaf.

      As a rule of the thumb I’d choose the following stack when using any kind of SQL data store:

    • automatic database migrations using Flyway or Liquibase

    • JPA / Hibernate together with Spring Data JPA as long as I can express my domain model as entities and tables

    • JPQL queries if necessary with the benefit that they are checked at application start

    • No native queries hidden away in some annotations

    • If I have to do native queries, I’ll choose Springs JDBC template or since 2015 jOOQ if applicable.

    • My rule for switching to native queries is when I do have projections or „hard“ analytics that would take an awful lot of Java Code instead of a few lines SQL.

  3. Why did you choose Hibernate ORM and Search over other frameworks and did it match your expectations?

    From my background, the data model has always been essential. I worked with awesome models and not so great ones. If you can map your domain to a data model, having a working domain driven design, Hibernate helps you a lot to materialize it back into Java.

    We want to publish articles (posts) and events on the site. People should be able to register for those events, one time each. This fits perfectly into a simple and well understandable domain model that maps perfectly to objects and entities.

    Why bother writing those plain SQL statements for selecting and updating stuff myself?

    I chose the combination of Hibernate and Spring Data JPA for a reason: The domain I map in Hibernate facilitates all the „magic“ Spring Data JPA does: Generating queries, conditions and such: I hardly have to write anything myself.

    If you chose JPA / Hibernate ORM in your project, I really recommend adding Spring Data JPA to the mix. Even if it’s a Java EE project. Spring Data JPA is a bit harder to configure there but provides the user with a lot of helpful stuff.

    Using Hibernate Search integration was an experiment. I’m using it for a long time now on my daily photo project. With little effort, my entities provide access to a Lucene based index and I don’t have to fight with SOLR.

    The EuregJUG site has no local storage in contrast to my daily photo project. So, I had to test drive the upcoming Elastic Search integration in 5.6.0, which works with the same set of annotations, the same entities but not against a local index but against a remote Elastic search index. You can see it in those commits described here and use it here.

    It really isn’t much stuff added, it fits into the repository / DDD approach and matches my expectations.

    Regarding Spring Boot, I’ve been doing Spring now for more than 7 years and Boot since early 2014. It has an awesome community and actually never disappointed me.

  4. We always value feedback from our users, so can you tell us what you’d like us to improve or are there features that we should add support for?

    As a Hibernate user the most common problems I had during the time which I didn’t know exactly what I was doing: Having problems mapping my tables, slow queries and such. Also throwing Hibernate at problems that would have been a better fit for plain SQL caused problems. In both cases, those problems could be solved on my end.

    The experience in Hibernates bug tracker is improving a lot lately and I would appreciate an even better integration with Spring Data JPA.

    To close this, I have to say that I really like the stack mentioned above. We have reached a quality of component where you can really work well from a Domain Driven Design perspective, switch to SQL if needed and still having a clean architecture with clean, testable code. Problems that have been around 10 years ago most often gone.

    It’s really not hard to get an application up and running, including unit and integration tests. If you leave aside the hypes, you can concentrate on both actual problems and on enabling people to learn and do their jobs.

    I really like the fact that Hibernate Spatial find its way into ORM itself. If you have correctly mapped entities and you need to query them via spatial regions, that stuff is really helpful and works quite well. I’d appreciate more information there.

Thank you, Michael, for taking your time. It is a great honor to have you here. To reach Michael, you can follow him on Twitter.

back to top