-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add persistence exception handling section #7
Conversation
@@ -0,0 +1,82 @@ | |||
# Handling exception in persistence | |||
|
|||
Say, you have a code like this which throws exception: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps "throws an exception"?
There's actually a problem with this. Once an exception is thrown within a transaction, most drivers will now consider the transaction in an invalid state, and therefore further changes will fail (I think). For example, I think the code you have here will fail for PostgreSQL (though unfortunately I can't easily test that at the moment). |
Yes, generally speaking a DB exception must be caught outside the transaction because the DB will not necessarily throw an exception until commit in some cases (in this case imagine another thread doing the same insertion). In this particular example one could use the PersistUnique functionality. In general sometimes (and in this case) you can break up the transaction and catch errors outside it. |
Yes, infact the code doesn't work with the PostgreSQL backend. I have been little occupied in my day job. Will update the PR by this week. |
I have updated the code to handle it in a database like |
Looks better! |
LGTM too. |
Thanks for the feedback, merging it. |
Let me know if this is not idiomatic. I did a related post regarding this on the mailing list: https://groups.google.com/forum/#!topic/yesodweb/MKEqVZdfam8