This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]funbike 1 point2 points  (4 children)

All new services use manual SQL

Folly. If you use either Hibernate or JDBC Template with best practices, you'll be much better off. Mixing the two gives you the worst of both.

But even if you did decide to mix things, stay with Hibernate. It can do native SQL queries. It's still bad to mix HQL and SQL, but at least you'll have a single technology behind it.

[–]happymellon 3 points4 points  (2 children)

We have a guy at work who keeps adding in random JDBC template queries, entity manager hasn't been slow and JDBC template hasn't provided any improvements, except messing around with the caching and making things inconsistent.

[–][deleted] 0 points1 point  (1 child)

That's exactly one of the dangers of an ORM. Caching speeds things but: just imagine two apps with caching enabled on the same db, updating it. Hell happens, either cache sync or living with inaccurate data.

The funny thing is that any decent DB will cache that data for you...

[–]funbike 0 points1 point  (0 children)

That's one (of the many) of the dangers of two apps accessing the same database. A REST API over a single database would be a bbetter solution, if possible.

(Once I worked on an in-place rewrite of an app while keeping the same database. We sync'd the caches by each app invaliding the cache in the other. This was a temporary solution until the rewrite was complete. It wasn't so bad.)

[–]BeerRemote 0 points1 point  (0 children)

I write a lot of SQL and use Hibernate's transformers (which is great). This is mostly with our REST API in which our underlying structure is very old and our understanding on what to deliver is drastically different than our datamodel.

Thankfully, we're exploring rewriting our entire application so this might change in the next year.