History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: GRAILS-3085
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Graeme Rocher
Reporter: Marcel Overdijk
Votes: 1
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Grails

Document a best practice using GORM delete() with failure

Created: 09/Jun/08 09:29 AM   Updated: 18/Jun/08 06:32 AM
Component/s: Persistence, Documentation, Scaffolding
Affects Version/s: 1.0.3
Fix Version/s: None

Time Tracking:
Not Specified


 Description  « Hide
The user guide has no documentation (at least I couldn't find it) about how to deal with failing GORM delete() calls. for example in case of a violating foreign key. There a nummerous post/questions about this on the user forum but as not all questions were answered it's difficult to find a good answer/best practise. I think it would aid developers to provide an example in the 5.3.2 Deleting Objects of the user guide (http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html#5.3.2 Deleting Objects)

Currently I implemeted it using flush:true and a try/catch:

def delete = {
        def country = Country.get(params.id)
        if (country) {
            try {
                country.delete(flush: true)
                flash.message = "Country ${params.id} deleted"
                redirect(action: list)
            }
            catch (org.hibernate.exception.ConstraintViolationException e) {
                flash.message = "Country ${params.id} not deleted"
                redirect(action: show, id: params.id)
            }
        }
        else {
            flash.message = "Country not found with id ${params.id}"
            redirect(action: list)
        }
    }

On a related note, it might be an idea to add this to the default scaffolding. Because if you have a one-to-many without belongsTo, and you try to delete the one side you will get a feedback message that the record was deleted, but in fact it was not deleted due to a ConstraintViolationException.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Sven Lange - 18/Jun/08 06:32 AM
Related to GRAILS-563