Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0.3
    • Fix Version/s: 1.1.1
    • Component/s: None
    • Labels:
      None

      Description

      An explanation of the current behaviour and why it's not exactly ideal is given here:

      http://www.cacoethes.co.uk/blog/index.php?p=38

      One possible solution is to use the Hibernate's Session.setReadOnly() method to ensure that changes to a domain instance are not persisted at flush time if there are any binding or validation errors.

      Hopefully it would also be possible to call Session.setReadOnly(false) to make the changes persist if, for example, the save() succeeds after any binding errors have been manually rectified. It might be worth making the method available on domain instances directly too.

        Activity

        Hide
        Graeme Rocher added a comment -

        fixed now for good, with functional test

        Show
        Graeme Rocher added a comment - fixed now for good, with functional test
        Hide
        Ayub Malik added a comment -

        We are currently using grails 1.1.1 and are still experiencing this behaviour, when a domain object has a binding error the edit page is displayed with a validation error however the record saves when the flush occurs. The code where this fails is from the controller generated from the grails:generate-all command, the line where the error occurs is shown below:
         

         
        if(!employeeInstance.hasErrors() && employeeInstance.save()) {
         ....
        }
        

        This results in an object being saved in a partial state or in a state that fails the grails validation.

        Can you please advise if this has definetly been fixed in 1.1.1 and if not whether it is fixed in 1.2M1

        Show
        Ayub Malik added a comment - We are currently using grails 1.1.1 and are still experiencing this behaviour, when a domain object has a binding error the edit page is displayed with a validation error however the record saves when the flush occurs. The code where this fails is from the controller generated from the grails:generate-all command, the line where the error occurs is shown below:   if (!employeeInstance.hasErrors() && employeeInstance.save()) { .... } This results in an object being saved in a partial state or in a state that fails the grails validation. Can you please advise if this has definetly been fixed in 1.1.1 and if not whether it is fixed in 1.2M1
        Hide
        Rob Kirkbride added a comment -

        Can this be reopened as I believe the problem still occurs with Grails 1.1.1

        It seems to be related to http://jira.codehaus.org/browse/GRAILS-1793 which also is marked as resolved but we have to do Marc Guillemots suggestion to make things work. However, this still produces a WARN and stack trace.

        Thanks.

        Show
        Rob Kirkbride added a comment - Can this be reopened as I believe the problem still occurs with Grails 1.1.1 It seems to be related to http://jira.codehaus.org/browse/GRAILS-1793 which also is marked as resolved but we have to do Marc Guillemots suggestion to make things work. However, this still produces a WARN and stack trace. Thanks.
        Hide
        Graeme Rocher added a comment -

        We have implemented a different strategy to deal with this for 1.2-M1, i suggest you try that release before we reopening the issue

        Show
        Graeme Rocher added a comment - We have implemented a different strategy to deal with this for 1.2-M1, i suggest you try that release before we reopening the issue
        Hide
        Graeme Rocher added a comment -

        Bulk closing bunch of resolved issues

        Show
        Graeme Rocher added a comment - Bulk closing bunch of resolved issues

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Peter Ledbrook
          • Votes:
            3 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development