3 ms·

That's a fair criticism about auditing. Doing it through database triggers avoids the problem with audits being missed because of code that doesn't participate

That's a fair criticism about auditing. Doing it through database triggers avoids the problem with audits being missed because of code that doesn't participate in the Hibernate lifecycle (including native SQL queries and Criteria updates, yikes!). I will also concede that under some circumstances it's too slow to bring the data to the code, and instead you have to bring the code to the data (i.e. PL/PGSQL). The sort of speedup is mostly from eliminating round trips and data marshaling, however. That's not quite a like-for-like comparison of an ORM vs a mapper. The reason I stick to ORMs is mostly because of RAD tools that save me so much time. For instance, JHipster generates liquibase migrations and JPA entities. This gives me a relational schema very quickly. To avoid any "surprise" queries that tank performance, I do turn Hibernate's statement logging on when developing new features. Next time if I can find some more tools to help with an SQL-only + stored procedure approach, I'll give it a deeper consideration. Maybe convince your company to open source some of tools it has developed!

doctor_eval 7y ago
There is a lot of internal enthusiasm for open sourcing our tools, but we are heads down at the moment so it’s just a matter of time (or lack of). I think we will time it for the next pgAU conference so we can talk about it at the same time. I definitely agree with you that tooling is a big deal. We did spend a lot of time manually proving it out before we spent the time on the tools. It was a bit of a leap of faith but it quickly became obvious that we were onto something. And you’re right, the point of our approach was to move the code to the data. We deal with reasonably large, complex real time data sets Sotheby’s round trips and marshalling become the dominating contributor to total time. Hence our ability to improve some operations by 100x. I can see that if you have a familiar and reliable tool chain and a compatible use case then ORMs could be great. I think our problem was that we had neither, so it was never going to work out too well for us!

doctor_eval 7y ago

There is a lot of internal enthusiasm for open sourcing our tools, but we are heads down at the moment so it’s just a matter of time (or lack of). I think we will time it for the next pgAU conference so we can talk about it at the same time. I definitely agree with you that tooling is a big deal. We did spend a lot of time manually proving it out before we spent the time on the tools. It was a bit of a leap of faith but it quickly became obvious that we were onto something. And you’re right, the point of our approach was to move the code to the data. We deal with reasonably large, complex real time data sets Sotheby’s round trips and marshalling become the dominating contributor to total time. Hence our ability to improve some operations by 100x. I can see that if you have a familiar and reliable tool chain and a compatible use case then ORMs could be great. I think our problem was that we had neither, so it was never going to work out too well for us!