-
Notifications
You must be signed in to change notification settings - Fork 76
Why extended version
My first touch with ORM was with EJB 1.0 and let's just say that a lot of people have been scared by that beast. So when JDO came, even though it was cumbersome it looked pretty amazing. Not everyone could afford TopLink. Hibernate came right at that time with a strong community driven spirit. You could map any old legacy system it was awesome! And because of session caching and second level cache it solved all your perf problems. I can't recall anybody questionning it, Hibernate became the defacto persistence layer. No need to write all the fields for your insert or update. Sure now you have to deal with N+1, dirty cache, open session in view but that was worth the price.
I could not tell when skepticism started to hit... Probably later than most. I think when I start to do some performance work on basically a batch insert structure. I wrote on using pure jdbc and it was suprisingly fast! Doing the same with hibernate was difficult, no auto generated id and some configuration and was still no where as fast... Did I say no auto generated id?
Recently I've been working on a project with services that exposes quite a bit of data fetch from the db. And quickly you run into 3 kinds of problem
Depending of your db, the balance between those 2 will vary. If your using mysql .... Good luck. So you end up writing the sql yourself anyway.
You definitly need to use ScrollableResults. But then you need to manage the session cache or use a StatelessSession.
Just profile it, it is slow ...
If you spend time on all of these you might as well write purejdbc... try it and compare the perf.
So why again do we use hibernate?
- It can save your big object graph in one call
- It allows you to refactor your object model easily
- For performance thanks to the cache!
- I don't need to write SQL! YEah!
- I don't save a big graph of object... If you do then I still think it might appropriate.
- not sure about that one... In practice the cost is more on the database side than the java one.
- I end up writing SQL
- Performance is poor, I end up writing jdbc.
I think the problem is that most ORM solution are proposing a monolithic - And that's one in it - approach to solving quite distinct problem.
- lifecycle
- caching
- jdbc easing
- sql generation
- object mapping
Those problem are hard enough on their own...
I want to be able to pick and choose.
I like jdbc, and I like writing sql. I just want a Mapper
- a Mapper that offer perf very close to a hand written one.
- a Mapper that work with no config.
- a Mapper that will work on top of jdbc.
You can find libraries that does a few of those thing but not all the list. Constructor injection is rarely supported. And most of them wrap over jdbc forcing you to use those api to manage your query.
The closest to the performance goal was Roma. But Roma needs all the mapping defined as annotation. Also Roma is not very flexible on the mapping, your query need to have a one to one match to the mapping.
That's really where simpleFlatMapper comes from. The csv part was to try and do a mapper that would work in push mode instead of pull mode which was quite interesting.
You can use Jooq, it's very flexible and you can use it just to generate the query or manage the querying. Also you can use another Mapper in it like sfm.