{"id":32008,"date":"2016-01-30T20:52:24","date_gmt":"2016-01-30T15:22:24","guid":{"rendered":"https:\/\/tothenewco.pro\/blog\/?p=32008"},"modified":"2016-02-08T15:07:29","modified_gmt":"2016-02-08T09:37:29","slug":"hooking-into-the-instance-methods-of-the-gorm-api","status":"publish","type":"post","link":"https:\/\/tothenewco.pro\/blog\/hooking-into-the-instance-methods-of-the-gorm-api\/","title":{"rendered":"Hooking into the Instance methods of the GORM API"},"content":{"rendered":"

In my grails plugin I was needed to add some fields that were common to a set of domains. For eg: for some domains we wanted to store fields like createdBy and lastUpdatedBy to keep track of users who created and last updated each record in that domain.<\/p>\n

Grails framework<\/a> provides timestamping using which we can keep track of the time a record was created and last modified, but doesn’t provide something for user stamping. Although there is a grails plugin named Audit Logging Plugin<\/code>, that provides this feature. But this plugin has its own limitations and was not a perfect choice for our case. I’ll discuss the issues with this plugin and the possible solutions in my next blog. Apart from these two fields you may want to add some other fields that are common to multiple domains and their values are populated based on some business logic.<\/p>\n

So how to handle this:<\/strong>
\nOne way to handle this scenario is by extending the GormInstanceApi<\/code>. This is the class that contains all the GORM persistence methods which are available to each domain in Grails application. An instance of GormInstanceApi is injected to each domain class which is used to invoke the persistence methods. We’ll use the decorator design pattern here to override the default instance of GormInstanceApi in each domain.<\/p>\n