ORM frameworks used for insert only / query only apps

Question

I've been using Hibernate for years and never have a problem with it, but just realized most of my work involved a CRUD approach, where I needed data to stay persisted and modified at will.

The problem with this is that there is people who want to make 2 separate apps, one that bulk inserts and another that performs search on the inserted data.

Since the persistence is a bit useless in this case, the team wants to not use Hibernate but to use raw queries on the insert app and maybe something like jOOQ on the query app.

Is that the right call? or how could I convince them to use Hibernate, other than "its my favourite orm framework"? Or are there even other solutions that haven't been taken into consideration?

Answer 1

Disclaimer: I'm the creator of jOOQ and thus, this answer is slightly biased.

jOOQ was designed precisely for the use case your coworkers mention. In your project, you're not doing OLTP (CRUD) but OLAP, which is a very good use case for jOOQ in many aspects. jOOQ encourages using OLAP features, such as window functions, pivot tables, recursive queries, stored procedures, arrays and unnested arrays, etc. jOOQ also supports 13 different databases with all the SQL compatibility subtleties that you want to avoid. Some examples:

• How are LIMIT .. OFFSET / TOP .. START AT, etc clauses mapped to a database?
• How are variables bound (with or without casting)?
• How are built-in functions supported?
• Do derived tables need to be wrapped in parentheses?

All of these compatibility aspects are very well covered by Hibernate as well, though. So your question comes back down to this:

• Do you want to use Hibernate which is not the perfect technology choice, but which you know well and thus can estimate the risks? This is the way to go if everyone on the team knows and likes Hibernate and there is little time to learn new things.

• Or do you want to use a different framework that might be more suitable, but you do not know it well and thus cannot estimate all the risks? This might be the way to go if you're the only one in favour of Hibernate and you have the time to learn new frameworks. Other frameworks you might want to consider:

  • Spring with JdbcTemplates (which can be combined with jOOQ, btw.)
  • myBATIS, which is known to handle SQL well.
    
    

• Or you can mix technologies and use Hibernate for simpler queries and plain SQL / jOOQ / Spring / myBATIS / etc. for more complex ones.

• Or can you handle bulk processing and OLAP querying using stored procedures (e.g. in PL/SQL if you're using Oracle) and let the database do the work? This might be the way to go if you have a good DBA or database-specialist on your team.

There is no right or wrong answer. But you will have to make a pragmatic decision.

Answer 2

Hibernate is an Object Relational Mapping. If they only do bulk inserts and reporting on raw data streams, maybe they don't need any object representation. Hibernate will come in handy if they need some sort of object representation of their data.

Answer 3

This is very possible. Hibernate plays very well with databases that are simultaneously updated by other applications. The only gotcha is Hibernate's internal caching timeout. This means that there could be a slight delay (couple of minutes) between a record being updated in the database and Hibernate seeing the updated data. I believe this is configurable.

Any argument for preferring Hibernate over JooQ is going to be one of how the application conceptualises the data. Hibernate abstracts the row representation of the data into objects. Some programmers don't like that and prefer to do it by hand. This might be the reason they want to use JooQ, so you need to talk to them about application structure.

Answer 4

sormula is a CRUD-ready ORM. You can mix JDBC with sormula. It does not do bulk inserts but it does have insertAll(java.util.Collection) to insert a collection of objects.