Using Grails 2.0.x without the new GORM API - possible?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Using Grails 2.0.x without the new GORM API - possible?

Roshan Dawrani
Hi,

"What's new in Grails 2.0" [1] says: "The GORM API has been formalized into a set of classes (GormStaticApi, GormInstanceApi and GormValidationApi) that get statically wired into every domain class at the byte code level."

If I remember it right, earlier it was the "hibernate" plugin that used to add GORM API to domain classes. Can someone please tell how it happens in Grails 2.0.x? Is it possible to skip adding the new GORM API (GormStaticApi, GormInstanceApi and GormValidationApi) to a particular application's domain classes? Can I avoid wiring of these GORM API methods into domain classes at bytecode level?
Reply | Threaded
Open this post in threaded view
|

Re: Using Grails 2.0.x without the new GORM API - possible?

Jeff Scott Brown
On Fri, Mar 23, 2012 at 7:04 AM, Roshan Dawrani <[hidden email]> wrote:
> Hi,
>
> "What's new in Grails 2.0" [1] says: "The GORM API has been formalized into
> a set of classes (GormStaticApi, GormInstanceApi and GormValidationApi) that
> get statically wired into every domain class at the byte code level."
>
> If I remember it right, earlier it was the "hibernate" plugin that used to
> add GORM API to domain classes. Can someone please tell how it happens in
> Grails 2.0.x?

Much of the interesting relevant work is related to the
HibernateGormEnhancer.  That class is used by HibernatePluginSupport.

See:
https://github.com/grails/grails-core/blob/master/grails-hibernate/src/main/groovy/org/codehaus/groovy/grails/orm/hibernate/HibernateGormEnhancer.groovy
https://github.com/grails/grails-core/blob/master/grails-hibernate/src/main/groovy/org/codehaus/groovy/grails/plugins/orm/hibernate/HibernatePluginSupport.groovy

> Is it possible to skip adding the new GORM API (GormStaticApi,
> GormInstanceApi and GormValidationApi) to a particular application's domain
> classes? Can I avoid wiring of these GORM API methods into domain classes at
> bytecode level?
>

Why is it that you might want to do that?  The answer to that question
will help answer your question and/or provide suggestions that might
be a better way to accomplish whatever you are after.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Using Grails 2.0.x without the new GORM API - possible?

Roshan Dawrani
On Fri, Mar 23, 2012 at 6:29 PM, Jeff Brown <[hidden email]> wrote:

> Is it possible to skip adding the new GORM API (GormStaticApi,
> GormInstanceApi and GormValidationApi)

Why is it that you might want to do that? 

Thanks for getting back.

On 1.3.x line, we replaced GORM stuff provided by Hibernate plugin and wired our own components for our own data-store (xyz).

Although a good idea will probably be to plug-in the new data-store based implementation for our xyz datastore, I am trying to see if I can avoid it in the round 1 of Grails 2.0 migration and re-use the existing data access layer. For now, we would like to focus on migrating the rest of the application, if possible.

Would you like me to provide any more details, or is it clearer what I am after? Is it possible to avoid hard-wiring of new Grails 2 GORM API into my app's domain classes? What do you suggest?

Regards,
Roshan
Reply | Threaded
Open this post in threaded view
|

Re: Using Grails 2.0.x without the new GORM API - possible?

Roshan Dawrani
Hi,

Ping!

Can anyone comment on if it is still possible to plug-in a 1.3.7 like custom GORM implementation (persistence layer) for an application bypassing the wiring of new GORM API methods into the domain classes?

Or, the only approach that would work with 2.0.1 is to plug-in an implementation of new GORM api for our own custom datastore?

Cheers.
http://roshandawrani.wordpress.com/ 

On Fri, Mar 23, 2012 at 6:40 PM, Roshan Dawrani <[hidden email]> wrote:
On Fri, Mar 23, 2012 at 6:29 PM, Jeff Brown <[hidden email]> wrote:

> Is it possible to skip adding the new GORM API (GormStaticApi,
> GormInstanceApi and GormValidationApi)

Why is it that you might want to do that? 

Thanks for getting back.

On 1.3.x line, we replaced GORM stuff provided by Hibernate plugin and wired our own components for our own data-store (xyz).

Although a good idea will probably be to plug-in the new data-store based implementation for our xyz datastore, I am trying to see if I can avoid it in the round 1 of Grails 2.0 migration and re-use the existing data access layer. For now, we would like to focus on migrating the rest of the application, if possible.

Would you like me to provide any more details, or is it clearer what I am after? Is it possible to avoid hard-wiring of new Grails 2 GORM API into my app's domain classes? What do you suggest?

Regards,
Roshan



--
Roshan
Reply | Threaded
Open this post in threaded view
|

Re: Using Grails 2.0.x without the new GORM API - possible?

Jeff Scott Brown
On Mon, Mar 26, 2012 at 8:35 AM, Roshan Dawrani <[hidden email]> wrote:

> Hi,
>
> Ping!
>
> Can anyone comment on if it is still possible to plug-in a 1.3.7 like custom
> GORM implementation (persistence layer) for an application bypassing the
> wiring of new GORM API methods into the domain classes?
>
> Or, the only approach that would work with 2.0.1 is to plug-in an
> implementation of new GORM api for our own custom datastore?
>

In general, the runtime metaprogramming techniques used in 1.3.x will
still work in Grails 2.  There are some things that could potentially
go wrong but if you take care, you should be ok.  For example, methods
added at runtime via the metaclass are only available to calls made
from Groovy.  Consider a methodA calls methodB and methodB calls
methodC and all of those are Java methods added at compile time.  If
you metaprogram your own version of methodA and methodC and your
methodA calls the original methodB, that could be problematic since
your dynamic methodA will call the statically compiled methodB and
that code will be calling the statically compiled methodC, not your
runtime metaprogrammed methodC.

I hope that makes sense.

Best of luck.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Using Grails 2.0.x without the new GORM API - possible?

wwright
 - Dynamic Datasource -

Thanks in advance, for reading my post.

I am a novice.  I have never posted a question, but have read through many posts for the past 3 years.

I have created a couple of Grails applications with good success, however my recent attempt has put me in a hole.  I have a basic understanding.   When I ran the debugger and started looking through the Meta data it seems there is no easy way to re-initialialize the GormStaticApi for the Domain.  

Here is the problem.

I attempted to create an application where by you have the DataSource.groovy Configed to a default database connection using H2 server such as:

url=jdbc:h2:~/company/it/projects/defaultProject/appleDb

In the application you can import some CSV data into the database, create some other data and export the data to CSV tables for some other device to consume. - This is termed a "project" i.e. the database is the project and we are trying to create a new database for the user and switch from project to project in the application.

The app allows you to say "new" project which creates a name i.e. "db1"  copies an initial database to the location.  This creates a new database and attempts to modifiy the dataSource and connect.

For instance switch to newly created directory with new initial database.

previous:
   url=jdbc:h2:~/company/it/projects/defaultProject/appleDb

current:
   url=jdbc:h2:~/company/it/projects/db1/appleDb

Below are the basic implementation of changing the datasource, which works, except for lingering Datasource refrences in the GormStaticApi  so for any domain such as Project.findAll() is still referencing the "defaultProject" and not the new datasource "db1"

It partially works...i.e. appears any thing performed in this request is not updated with the new datasource, but subsequent requests seem to have the updated datasource.

Since I barely understand what you have prescribed above...I am reluctant to even discuss here.


    /**
     * createNewBasicDataSource(newurl,cfg)
     * @param newurl - the targetUrl to use for creation
     * @param cfg -datasource config data
     */
    def createNewBasicDataSource(newurl,cfg)
    {
        def newds = new org.apache.commons.dbcp.BasicDataSource()
       
        newds.setUrl((String) newurl)
        log.info("newds.setUsername("+cfg['username']+")")
       
        newds.setUsername(cfg['username'])
        newds.setPassword(cfg['password'])
        log.info("newds.setDriverClassName("+cfg['driverClassName']+")")
        newds.setDriverClassName(cfg['driverClassName'])
        newds.setDriverClassName(cfg['driverClassName'])
        newds.setDriverClassName(cfg['driverClassName'])
        newds.setDriverClassName(cfg['driverClassName'])

        def props = cfg['properties']
        props.each{k,v ->
            newds.addConnectionProperty(k, String.valueOf(v))    
        }
        return newds

    }


    def setProjectName(name)
    {
        def file
        Project newProjectRecord
        def db
       
       
        if (name == null) return 1

        def newurl = "${grailsApplication.config.urlPrefix}/${name}

        grailsApplication.config.projectname = name
        grailsApplication.config.dataSource.url = newurl

        try{
            def ds = dataSource.getTargetDataSource()
            def newds = createNewBasicDataSource(newurl, grailsApplication.config.dataSource)

            // Set new datasource
            newds.createDataSource()
            newds.createConnectionFactory()
            newds.createConnectionPool()
            dataSource.setTargetDataSource(newds)
           
            // Close previous
            ds.close()
           
        }
        catch (Exception dsc)
        {
            log.info("** Exception - while closing setProjectName() datasource")
            log.info(dsc)
        }
       
               newProjectRecord =  Project.list(max:1)[0]
                   

                // Set the Project Name in the New database.
                // NO Project Record .. must be new project

/***
  Problem
  we are still Project.list() pulled from the previous Database (defaultProject) and so we are updating the   wrong dbase.   But subsequent requests show we using the new datasource (db1) as created above.

*/

                if (newProjectRecord == null)
                {
                    log.info("New Project")
                    newProjectName(name)
                    return 1
                }
                else if ( newProjectRecord != null)            
                {
                    newProjectRecord?.name = name
                    newProjectRecord?.modified = new Date();

                    if (newProjectRecord.save(flush:true))
                    {
                        log.info("saved project name true, name "+ newProjectRecord.name)
                        return 1
                    }
                    else
                        return 0
                }
                else
                {
                    log.info("Failed to Change Project Name.")
                    return 0
                }
            }

    }