Dynamic DB schema for GORM - Patch for 1.1 to set Hibernate EntityInterceptor on sessionfactory (GRAILS-4651)

[Henrik Fjorback]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi!

 

We just submitted a patch for Grails 1.1+ that allows you to define your own entityInterceptor in resources.groovy.

http://jira.codehaus.org/browse/GRAILS-4651

 

We need our own interceptor in order to modify the sql statements at runtime, since we have to set the proper schema, and we still want to benefit from all the GORM magic!

Since 1.1 we believe the solution is now even cleaner than with 1.0, since Grails does no longer use the entityInterceptor property.

By simply defining your own bean, “entityInterceptor”, in resources.groovy – you will have full access to any prepared SQL statements, prepared by GORM.

 

Thanks to Burth Beckwith, we made this work with Grails 1.0, but since 1.1 this solution is no longer possible.

http://markmail.org/message/ymbksp4gjxfabh6a

 

We DON’T want to start  a flame war about whether or not having multiple identical schemas is a good idea or not. With a strong IBM i(aka. AS/400) background, we can tell that this scenario is very common in our environment.

 

We haven’t figured out how to encapsulate this exact behavior inside a plugin – besides creating the datasource inside the plugin as done with the “Datasources” plugin.  With this scenario we find that approach a bit too risky, since it duplicates the creation of session factory already done by Grails.

 

 

Regards

Multi-Support R&D A/S

 

Henrik Fjorback

--------------------------------------------------------------------

Phone [phone], Fax [phone]

E-mail: fjorback@...

http://www.multi-support.com

 

[Graeme Rocher-3]

Thanks for the patch, we will include it in the next release

On Mon, Jun 22, 2009 at 11:00 AM, Henrik
Fjorback<fjorback@...> wrote:

> Hi!
>
>
>
> We just submitted a patch for Grails 1.1+ that allows you to define your own
> entityInterceptor in resources.groovy.
>
> http://jira.codehaus.org/browse/GRAILS-4651
>
>
>
> We need our own interceptor in order to modify the sql statements at
> runtime, since we have to set the proper schema, and we still want to
> benefit from all the GORM magic!
>
> Since 1.1 we believe the solution is now even cleaner than with 1.0, since
> Grails does no longer use the entityInterceptor property.
>
> By simply defining your own bean, “entityInterceptor”, in resources.groovy –
> you will have full access to any prepared SQL statements, prepared by GORM.
>
>
>
> Thanks to Burth Beckwith, we made this work with Grails 1.0, but since 1.1
> this solution is no longer possible.
>
> http://markmail.org/message/ymbksp4gjxfabh6a
>
>
>
> We DON’T want to start  a flame war about whether or not having multiple
> identical schemas is a good idea or not. With a strong IBM i(aka. AS/400)
> background, we can tell that this scenario is very common in our
> environment.
>
>
>
> We haven’t figured out how to encapsulate this exact behavior inside a
> plugin – besides creating the datasource inside the plugin as done with the
> “Datasources” plugin.  With this scenario we find that approach a bit too
> risky, since it duplicates the creation of session factory already done by
> Grails.
>
>
>
>
>
> Regards
>
> Multi-Support R&D A/S
>
>
>
> Henrik Fjorback
>
> --------------------------------------------------------------------
>
> Phone [phone], Fax [phone]
>
> E-mail: fjorback@...
>
> http://www.multi-support.com
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email