[rbirkby]

Perfect example of the trough of disillusionment. The ORM slope of enlightenment comes when you realise the power of the unit of work, not just a single query. But that was then, and microservices mean we no longer use large units of work. So ORMs without complex UoW make less sense.

[swyx]

I've never come across this unit of work concept. care to elaborate or recommend a link to learn more?

[hipnoizz]

This is I think primarily related to transaction boundaries and tracking changes. You can read https://www.martinfowler.com/eaaCatalog/unitOfWork.html as a starting reference. I haven't heard this phrase much lately to be honest. ;)

In 'typical' Java application (since many comments here as well as the original article mentions Hibernate...) you will likely use annotations like @Transactional to mark your transaction boundaries (likely with default propagation and isolation levels...) and then Hibernate will track any changes ('dirty checking') to objects you asked him to fetch and then at the end the transaction Hibernate will issue whatever DML commands (INSERT, UPDATE, DELETE) needs to be issued in an appropriate order.

In a galaxy far, far away i.e. before Java 1.5 instead using @Transactional you would maybe use (write) some object like TransactionManager which provides an execute() method that receives a block of code in a form of a interface implementation (no closures for you!). This part is relatively straightforward. Tracking changes in any semi-automatic way was always messy...