> 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.) > > I guess the reason behind this is that when a database exception is thrown, it is too difficult to figure out which parts of the session objects graphs are invalid or should be restored. This would require a very complex system, if at all feasible. In the hibernate philosophy, you should just discard the session, log the exception somewhere and perhaps show some message or throw a 500 error. In many apps it's actually acceptable, many DB framework wraps jdbcExceptions into some random unchecked exception class because in most cases, other than apologizing to the user, there is not much that can be done.
I agree it's a problem when you want to treat some predictable exceptions as non fatal (issuing a delete, watching for FK violation, and print "no sorry, record is in use")... As for detaching, reattaching objects, I'd just say no thanks! Detached objects are to be considered stuffed with TNT, I'd rather use IDs and DTOs which I know are safe and serializable. In a transaction oriented app it's usually fine if you keep it stateless. > I guess you need that. > Record classes to represent rows, and a relationship representation to > know what foreign keys to follow. > I like this approach that let you choose which relations you need and control when they are loaded. The biggest problem is that when using such records classes some parts of the graphs may not have been loaded, so you'll always need to know how the data were loaded. That being said, if you keep your data loading stuff close enough to the code using it and don't pass half filled data objects everywhere, you should be fine. I am not a big fan of reusable DAO classes anyway, I only create them for the most common and simple entities. -- 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.
