Evict object from Hibernate in update Methods.

You can use discard(). We used to evict, but it causes problems as the associations might still be in the session, now we set the session flush mode to manual on a validation error. So the changes don't get flushed to the db on a validation error, you can still force them to be using save(flush:true) to recover from a validation error programmatically, but as far as I'm concerned this issue is not an issue

Just to be clear validation executes as part of the called to save(), if save() fails to validate the flush mode is set to manual, hence you should always call save() when doing updates

I found a solution for the problem in the Mailing list by Graeme himself

page.discard() does it.

But the discard() method isn't used by the generate-all (scaffolding) command? I can't find it in the templates!?

Its not needed, because we call save() in the templates if a validation error occurs the flush mode will be set to manual preventing the changes from being flushed

I tryed it with:

if (!u.hasErrors() && u.save()) {
                    request.message = "User ${params.id} updated"
                    redirect(action: 'index')
...

but "u.properties = params" has already changed my database values!!

So it's senseless to set the flush mode to manual, because the "flush" has been already performed.

I've done it now with the ".discard()". But if the Hibernate session is flushed when I modify my properties values, how can it be transaction save (lost update anormalies etc.)?

hmm this shouldn't happen, please post a sample application with steps to reproduce, in the meantime you have the dicard() workaround

Ok, i'll create a sample application.

So you should give the Issue a lower priority?

i think we should try and find a solution for 1.0.2 or 1.1 but i wouldn't say its a blocker, in my tests the changes were not being flushed on validation error so its seems a particular set of circumstances that is causing your changes to be flushed. Also you have a workaround

Well the problem with the workaround is that by calling discard() on the object, you will get a lazyinitialization exception in the view if your view needs access to collections on the object being updated.

Some sample code from my grails console to illustrate:

def clientService = new com.myCompany.service.ClientService()
def client = clientService.getClientByName("Test")
client.name = "Test2" // This name is already taken, violating a unique constraint
clientService.updateClient(client) // Service calls validate and returns on failure, setting errors into object
if (! client.hasErrors()) {
// This block doesn't get reached for this example do to the validate failing in the service
} else {
// We have to discard or we get exception do
// to hibernate saving the changes we made to object
client.discard()
// Forward to page
client.errors.each

// But this fails after discard since jobs is a collection that has not been initialized yet. It's needed in the page.
println client.jobs
}
return client

By the way, "we call save() in the templates if a validation error occurs the flush mode will be set to manual preventing the changes from being flushed". This statement is only true if being called directly in the controller. But calls to save() in a service to not set flush mode to manual as my tests confirm.

Currently in the case of a service if you get a validation error you should throw a runtime exception which will rolllback the transaction

Not sure if this is related but with 1.0.2 scaffolding when we delete we are getting:

Caused by: org.springframework.dao.DataIntegrityViolationException: not-null property references a null or transient value: Stockist.type; nested exception is org.hibernate.PropertyValueException: not-null property references a null or transient value: Stockist.type
at StockistController$_closure4.doCall(StockistController.groovy:27)
at StockistController$_closure4.doCall(StockistController.groovy)

The line of code is the stockist.delete()

    def delete = {
        def stockist = Stockist.get( params.id )
        if(stockist) {
            stockist.delete()
            flash.message = "Stockist ${params.id} deleted"
            redirect(action:list)
        }
        else {
            flash.message = "Stockist not found with id ${params.id}"
            redirect(action:list)
        }
    }

The object being deleted has a "type" property that is null in the db due to it being old data before the property existed, and the Stockist class now has this property with a default value assigned to it:

class Stockist {
    String name
    String nameOrNumber
    String addressLine1
    String addressLine2
    String town
    String county
    String postCode
    String type = Schema.STOCKISTTYPE_PUB
    
    static mapping = {
        cache usage:"nonstrict-read-write"
    }
    static constraints = {
        name(size:1..60, blank: false, nullable: false)
        nameOrNumber(size:0..60, blank: true, nullable: true)
        addressLine1(size:1..60, blank: false, nullable: false)
        addressLine2(size:0..60, blank: true, nullable: true)
        town(size:1..60, blank: false, nullable: false)
        county(size:0..60, blank: true, nullable: true)
        postCode(size:1..10, blank: false, nullable: false)
        type(size:1..20, blank:false, nullable: false, inList:Schema.STOCKISTTYPES)
    }
}

So the issue here is that it seems to be trying to SAVE when we call delete() which surely should not be happening, and makes me think this is related?

Hi Marc,

The delete() method simply calls session.delete(), so I think this is down to Hibernate. Just found a hibernate bug report that looks relevant to the behaviour you're seeing.

I'm going to send a mail to the dev list about this issue, but I think we should move it to 1.1 since it will almost certainly require a fairly significant change. We may switch to using the readOnly property on Hibernate domain instances, but we need to think on exactly how things should behave.

Grails not sets the object to read-only if a validation error occurs or a data binding error occurs, eliminating the lazy load problems that result from using discard()

This is excellent news. Thank you very much for this.