0

I'm new to Grails and I'm facing some problems sharing my domain model between three different applications. Two of them need to persist model objects, and the third don't.

It seems the usual approach to manage this is by the creation of a plug-in and putting the domain classes in it. The problem is that the domain classes include specific persistence information, and there are some differences in the way each application persists the objects. Moreover, one of the applications does not need to persist those objects at all, as it retrieves and deletes them using a JSON web interface from another. When I run this application in mode dbCreate = "create-drop", Grails creates unwanted tables for those classes on startup.

I think all the problem comes from mixing the model and persistence specific information in the domain classes. How can I solve it? Is there a better approach I'm missing to share domain model?

dmahapatro
  • 49,365
  • 7
  • 88
  • 117
Leo Lobeto
  • 364
  • 3
  • 14
  • 1
    Personally, I think you would have to explain why the different applications need to persist the objects differently. Also, if you are creating them from JSON web services, is the model not there as well (4th place)? Please explain the situation with actual examples. – James Kleeh Jun 11 '13 at 18:18
  • The difference in persistence between both applications is subtle. Some application may want to use lazy retrieval or embed classes in parent table. The reason is that one of them will act as a cache for objects in the other application. Those differences are not already defined, but the goal is to allow them to have independent configuration. – Leo Lobeto Jun 11 '13 at 19:29
  • The domain objects will be used for persistence in two applications and for serializing/deserializing as JSON. The latter is the most problematic case, because I can use the same persistence configuration if I have no choice, but I don't want the creation of unnecesary tables (or any overhead implied by persistence) in an application that doesn't need persistence. – Leo Lobeto Jun 11 '13 at 19:30
  • I'm not sure why anything would create unnecessary tables. Any Grails application that is in "production" should be using database migrations. The `dbCreate` settings are for development only. – James Kleeh Jun 11 '13 at 19:44

1 Answers1

1

Your approach is correct, in having a plugin with all the domain classes. This approach is suitable for having multiple configuration for dataSource and not manipulating the behavior of the plugin. In order to achieve the same you can modify the dataSource in each application accordingly. For example, something like below:

//Application 1:
//DataSource.groovy
dataSource{
    environments{
        production{
            .........
            dbCreate = "update"
            url = "prod db url"
            ..........
        }
    }
}

//Application 2: [Similar to Application 1]
//DataSource.groovy
dataSource{
    environments{
        production{
            .........
            dbCreate = "update"
            url = "prod db url"
            ..........
        }
    }
}

//Application 3: [which does not persist model to db]
//DataSource.groovy
dataSource{
    environments{
        production{
            .........
            //anything other than update, create-drop, validate does nothing
            //Taking into consideration you already have the tables created from 
            //any of the other application.
            dbCreate = "none"
            url = "prod db url"
            readOnly = true //To be on the safer side
            ..........
        }
    }
}

The same behavior is applicable for other environments. Refer DataSource for more insight on its properties.

In case you already have the tables and want to generate the domain classes for those tables, you can use db-reverse-engineer plugin effortlessly.

Although, you can use multiple datasources if you need other connections to be used from Application 3.

dmahapatro
  • 49,365
  • 7
  • 88
  • 117
  • The third application doesn't persist objects of this model, but it does persist other objects. It's a front-end application, and as such, it persists sessions and some activity related information. – Leo Lobeto Jun 11 '13 at 19:36
  • As I commented below my question, the difference in persistence between both applications is about lazy retrieval or embedded classes. This kind of things are specified in the class declaration, so they are inherently shared. – Leo Lobeto Jun 11 '13 at 19:42
  • Well in that case, you cannot achieve that from a single plugin. It is like a Grails plugin behaving differently when used in different apps. I might have to change my answer. – dmahapatro Jun 11 '13 at 20:10
  • Moreover, I have updated the answer to use multiple dataSources in case you want Application 3 persisting other models in different persistence layer. – dmahapatro Jun 11 '13 at 20:14