Bye Bye CDI Query, Hello DeltaSpike Data

CDI Query started more than two years ago as an exercise on CDI extensions, open sourced from day one. Fortunately it made it’s way from a little toy project into something actually useful, also mainly thanks to many brave early adopters fixing bugs and bringing in new ideas. In case you are one of those early adopters, you might have noticed that activity on the CDI Query project on GitHub has gone down to zero the last few months.

This does not mean we have stopped working on CDI Query, in contrary. I’m happy to announce that CDI Query has been accepted as a new module on the Apache DeltaSpike project, a collection of CDI extensions resulting from a merge of Seam 3 and Apache CODI. The Apache team has been a great help improving both API and implementation, and the project is now available as a DeltaSpike module named ‘Data’ (similarities with other OSS projects are totally coincidential :-). A first version under the new home has already been released together with the overall DeltaSpike release train as version 0.5.

If you want to know more about DeltaSpike or DeltaSpike Data specifically, have a look at the official website or the current documentation snapshot of the Data module (until it has been properly moved to the DeltaSpike website).

Migration

We recommend all users of CDI Query to move forward with DeltaSpike Data. Not all features have been ported – in case you find something missing, please file an issue in the Apache JIRA.

Some important changes to note:

1. We have migrated away from Seam Solder, mainly from the Solder ServiceHandler. This has been replaced by the DeltaSpike PartialBeans which are a more elegant solution and in line with CDI interceptor bindings. This might have impact on your bean types as the type closure is not added to the bean type (yet). In case you had something like the following in your code:

you will have to replace this with the concrete inject.

2. The API has undergone some major renamings. We’ll cover those in the next section in detail.

3. EntityHome has not been ported. This API felt still unfinished. If you find it useful anyway, please let the DeltaSpike team know.

To get you started with a migration, exchange the previous CDI Query dependency with the new DeltaSpike Data dependency:

Most of the imports should be fixed by just running an organize import again. Other things which are still broken are explained in the next paragraph.

API Changes

DAOs go Repositories

The main change when it comes to naming has been done with the @Dao annotation and the base DAO classes. While DAO is a pattern name probably still known to old guys like myself, the younger generation is probably more used to the DDD-coined Repository term. Replace code like

with:

EntityManager Resolution

While EntityManager resolution still relies on a CDI producer, the way to deal with multiple EntityManagers has been changed to comply to other DeltaSpike modules. The following example illustrates the approach:

Query Changes

While the basic structure for the @Query annotation has been kept, the way a native query is defined has been changed. The query is entered in the value attribute, and a isNative flag is used to mark it as a native SQL execution:

Looking Ahead

While we’ve talked so far only about cut or modified features, there are also new things added to the API. Most notable additions are:

Mapping of Query Input / Results

Mapping of entities can be useful when your domain model is quite complex and your service layer needs only a limited view on it, or if you expose entities over an interface:

Optional Query Results

While the JPA spec requires to throw exceptions on getSingleResult() when there is no or more than one result, we’ve introduced the option to return either null or even just any result (the first one if there are more than one):

Feedback

As usual, we’d love hearing from the community (you). Having a great idea how to improve DeltaSpike Data? Found a bug? Reach out to the DeltaSpike mailing lists or JIRA!

Never miss an article by subscribing to our monthly digest!

Summary
Article Name
Bye Bye CDI Query, Hello DeltaSpike Data
Author
Publisher Name
Atos Consulting CH
Publisher Logo

5 thoughts on “Bye Bye CDI Query, Hello DeltaSpike Data

  1. Michel Graciano Reply

    Where can I get the updated documentation? The DeltaSpike website looks out-to-dated and I can see in the git repository that there are up-to-dated documentation but I was unable to find it published anywhere. Thanks in advance and congratulations by the interesting project.

    • Tom Hug Post authorReply

      Hi Michel,
      Updating documentation is definitely on the todo list for DeltaSpike (as plans are to move to a 1.0 release). I will have to figure out how to deal with the Apache CMS 🙂 but hopefully I’ll get the documentation ported properly soon.

  2. Matteo Reply

    Nice module!
    But how would you do dynamic queries? For example for a form where query parameters may be present or not? Do you have to construct queries by hand in such cases? In Seam there was EntityQuery, does something similar exist here?

    • Tom Hug Post authorReply

      Hi Matteo,
      I guess closest to what you have from Seam EntityQuery are the “findByExample” methods on the EntityRepository. You still have to figure out though which attributes you want to consider for the query. As mentioned in the article, the EntityHome in CDI Query supported this, but I wasn’t yet happy with the API to port it over.
      Good input though, will keep the suggestion in mind!

  3. Paolo Reply

    I think that We have to wait years before Seam 2 will be totally reimplemented in plain j2ee + DeltaSpike … i’ll never understand the decision of jboss to disassemble Seam 2 into j2ee + omnifaces + cdi + deltaspike + picketlink :(((((

Leave a Reply

Your email address will not be published. Required fields are marked *