> It wasn't intended to be handwavy at all. Okay.
> If I'm writing a batch-type job using Cayenne, I'm fine with it > dying completely on a commit error since it probably isn't safe > to continue. Heh. That's kind of zeroth-order approximation to dependency analysis: Assume everything depends on everything that came before it. My code does that, too, and my boss hates that with a passion. The only thing that's holding him back from ordering me to fix it is that I'm telling him I can't do reliable dependency analysis. Not getting useful diagnostics from the ORM is one of the factors that come into play here (there are others, such as higher priorities and constrained resources). > For the web applications I write, I catch Exception (anything) > and inform the user that there was a problem and their changes > weren't saved (I don't give them a stack trace or other > mumbo-jumbo they won't understand) and then e-mail the exception > to the developers so they can investigate. Doing the same here for the moment. > I find in practice this works better than trying to catch > individual exceptions because most of my user community wouldn't > understand an OptimisticLockException or any other kind of > Exception and I don't need multiple catch blocks just to e-mail > the developers the exception. This *is* a handwavy way to deal with an optimistic locking situation ;-P We could do better. For example, in the case of optimistic locking, we could tell the user "somebody else changed the data you were trying to update; here's the base where you both started, here's your change, here's the other person's change; do you want to override the other person's change, or do you want to repeat your edits based on their changes?" Plus add something that makes the overridden data available (clipboard, separate dialog window with the data snippets, whatever). Well, so much for the wishlist :-) Right now, I think Cayenne should document that it will detect optimistic locking failures but handles them like any unspecific problem: there is no special support for handling the situation. (I'm not aware of any ORM that actually does better than that, by the way. Lifting optimistic locking failures to the GUI abstraction level has been my personal elusive Quest Beast for more than a decade now, that's all.)
