JUNK RUNTAH

Auditing data with the Acegi plugin and Grails upgrade pain

Im in the middle of trying to upgrade our app (again). Were running on Grails 1.1 now and Im attempting to get us to 1.1.1 and from there to 1.2-M1. As Marc Palmer points out the more people using it the more likely it is that 1.2 final will be rock solid.

The problem thats biting us right now is GRAILS-4453 (or, more accurately, HHH-2763). Were using Grails Hibernate events support to track the user that created and last updated assets in our system. This isnt just us being anal, the site editors frequently search the data using those criteria so its an essential feature.

In Grails 1.1 this is simplicity itself. The following code goes in the domain class and thats all there is to it:

 User createdBy
 User updatedBy

 def authenticateService

 def beforeInsert = {
 createdBy = authenticateService.userDomain()
 }

 def beforeUpdate = {
 updatedBy = authenticateService.userDomain()
 }

Yes, it is quite exciting that youre able to inject a service into a domain class instance. GORM only maps explicitly typed properties to the database so anything declared using def is effectively transient.

Unfortunately Grails 1.1.1 includes a newer version of Hibernate that introduces a particularly horrible problem. When saving any update to our domain object now were faced with the error: collection [User.authorities] was not processed by flush(). The problem appears to be that the User instance attached to createdBy cannot be flushed when the beforeUpdate closure executes because it has a lazy-loaded collection of authorities. Even declaring the authorities collection as lazy: false doesnt help as the relationship is a bi-directional many-to-many - each Authority also has a collection of all the Users who have been granted that role. Given that for the purposes of displaying data to the audience of our site this audit data doesnt matter a damn I really dont want to be eager fetching it. Also, given the nature of the User-Authority relationship, casual eager fetching could result in rather a lot of data being loaded in to memory (the User, his roles, all the other users with that role, all their roles...)

Our options seem to be:

1. Explicitly eager fetch the User data in places where the owning object will get updated. Since the domain class in question is the root of a heirarchy of 13 sub-classes (things this project has taught me #63: never do this) and varieties get updated by a service or two, at least one controller and one Quartz and several hundred Selenium test fixtures, its going to be a massive PITA and just as bad to remove if/when HHH-2763 ever gets fixed.
2. Break referential integrity and store username or id rather than an actual domain object relationship. This feels horribly wrong and is likely to cause problems down the line.
3. Store the created/updated information as a domain object of its own. This would make the query to find data by who created or updated it more complex (although not impossibly so) and might actually be prone to the same original bug

I dont know if anyone might have come across this problem and has some kind of workaround (preferably one that isnt an evil hack). Id really appreciate any pointers.

Update: This is fixed in Grails 1.2-M2

Available link for download

Auto generate Spock specs for Grails artifacts

Available link for download

Avoiding accidental i18n in Grails

localResolver(org.springframework.web.servlet.i18n.FixedLocaleResolver, Locale.UK)

Available link for download

Asynchronous application events in Grails

import org.springframework.context.*

class EventService implements ApplicationContextAware {

 boolean transactional = false

 ApplicationContext applicationContext

 void publish(ApplicationEvent event) {
 println "Raising event $event in thread ${Thread.currentThread().id}"
 applicationContext.publishEvent(event)
 }
}

def eventService

void afterInsert() {
 eventService.publish(new DocumentEvent(this, "created"))
}

void afterUpdate() {
 eventService.publish(new DocumentEvent(this, "updated"))
}

void afterDelete() {
 eventService.publish(new DocumentEvent(this, "deleted"))
}

import org.springframework.context.*

class EventLoggingService implements ApplicationListener<DocumentEvent> {

 boolean transactional = false

 void onApplicationEvent(DocumentEvent event) {
 println "Recieved event $event in thread ${Thread.currentThread().id}"
 }
}

import java.util.concurrent.*
import org.springframework.context.event.*

beans = {
 applicationEventMulticaster(SimpleApplicationEventMulticaster) {
 taskExecutor = Executors.newCachedThreadPool()
 }
}

beans {
 applicationEventMulticaster {
 taskExecutor = Executors.newCachedThreadPool()
 }
}

Available link for download