>> I guess both the hate and the misuse come from >> misrepresentation. The "Hibernate in Action" >> book even goes to great lengths to explain how >> to do "long-running conversations that span >> multiple transactions". > > Does it?
The revised edition does. Christian Bauer, Gavin King 2007: Java Persistence with Hibernate. pp. 401 ff. "Working with detached objects" No mention of the StaleObjectStateException there. But I stand corrected: You can indeed reattach an existing Pojo to a Session. Via Session#lock. Talk about intuitive naming... pp. 423 ff. "Working with detached entity instance" Oh somebody tell me what the difference between an "object" and an "entity instance" is... oh right, it's the same chapter, but about JPA this time. Except no mention of lock() this time. But that's just tangential. The conversation beef is chapter 11: pp. 476 ff. "Implementing conversations" Talks about all variants: pp. 478 ff.: Conversation = Transaction = Session pp. 486 ff.: One conversation holding multiple Transactions = Sessions, detached instances survive between Transactions/Sessions pp. 489 ff.: Conversation = Session holding multiple Transations, objects stay attached (but that doesn't work as soon as the Session dies due to any exception) pp. 497 ff.: Next chapter (JPA) > I can't even imagine myself manipulating > detached, explosive objects. Well, I *thought* I could use the model described on pp. 489 ff. Except Sessions are too fragile - and no mention of that in the entire book. (Read that thing multiple times.) >> That's yet another issue. You can't use stored >> procedures if you want to keep migration costs > under control. Or, put another way: If you use >> stored procedures, you should keep the business >> logic in the database, and then any shitty ORM >> will do and you don't need Hibernate that much >> anymore. (...) Hibernate also doesn't even begin >> to handle bulk queries (...) > > Well, I am not a big fan of writing and maintaining > stored procedures but sometimes it's the best way > to handle bulk operations. 100% agreed. >> Sounds intriguing. >> Are there any whitepapers around? > > Not sure, it has been a while since I left my previous > job and I haven't used it since then. > It generated record classes that were somewhat similar > to Jooq, along with a representation of their > relationships. I guess you need that. Record classes to represent rows, and a relationship representation to know what foreign keys to follow. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
