Last Wednesday evening Sean Corfield and I were chatting over beers and he caught me by surprise with a statement he made. We were talking about the ORM functionality in CF9, and he liked how it just worked. You invoke a setter, and it gets to the database with nothing else. I agree in theory, but not in practice.
It had honestly never occurred to me that someone would actually want to have stuff get to the database without any control over it. Transactionality is such an ingrained part of my being that the mere thought of writing to the database outside an explicit transaction never even entered my mind.
There have been a number of discussions about transactions on the cf-orm-dev mailing list. Often prompted by someone mentioning some problem and me jumping down their throats about how they better use transactions. But here's a very experienced developer who I know full well intimately understands transactionality actually saying with complete honesty that he likes to have it just work.
I'm personally against this approach: if something goes awry your database could well get jacked, and no one wants that. Though I nearly always apply transactionals via AOP, and both Sean and I agreed that assuming AOP familiarity is unreasonable for people using CF9 ORM.
The conversation quickly moved on from there (I believe Scala was the next topic), but that brief moment of complete surprise stuck in my mind. I certainly don't claim to know it all, but I know that I have opinions that are not shared by everyone. However, the dismissal of ACID like that was a shock. I respect Sean's opinion very much, and while I will continue to wrap all my saves in a transaction, things are clearly not as cut and dried as I think they are.
I think the idea behind Hibernate is "it should just work".
A lot of effort has been put into making it quite intelligent. It's perhaps the most sophisticated ORM around, neh?
Plus, you can tweak the heck out of it (as I know you know). It doesn't /have/ to be simple, but it /can/ be, which is swell. Super swell, really.
It's not about *wanting* to /not/ have control, it's about practicality, IMHO. You're not *forced* to control everything if you don't want to.
Quite a bit of the time, I just want the data to "get in there", and don't need to get fancy with various types of transactions and special listeners and whatnot. Set it and forget it.
But it all depends, I reckon.
Neh?
I guess my opinion is that transactions are a business logic concern, not a persistence concern. The concept of non-ACID writes to the persistent store is flaw in the business layer, regardless of how the interactions are actually implemented.
Don't get me wrong, I very much love building an object model and then just letting Hibernate deal with the DDL and persistence operations. The speedup for development is HUGE. But that's an orthagonal concern to data consistency in my view. Fortunately, AOP can push transactions out of sight and out of mind, so getting the best of both worlds is really quite reasonable.
I'm not sure that business logic concerns and persistence concerns are separate deals.
It's one of the decisions we face as developers: How much business logic should be in the actual CFML code and how much should be in the DB.
And there's stuff like caching to think about, etc.. Maintaining consistency/state can be complex. Things can get muddy pretty quick.
And factor in that transaction handling is getting "smarter" all the time. Back in the day, you had to do a lot more "manual" locking-ish-ness, neh?
I'm amazed at how much Hibernate can do for you, right out of the box. Stuff that you used to have to do by hand… Eh.
Maybe persistence concerns *are* business logic concerns? Something like that…
Computers freaking rock. :)