unique question about sharing domain classes in a plugin

[dalew75]

I'm using the idea of sharing domain classes in a plugin like this:

1) App 1 is a source of data, having a database, and providing an API to access its data.
2) App 2 wants to use that API, but so does App 3 and App 4
3) So I made a plugin that contains the domain classes from App 1.  It also has a service class and tag library to make it easier to use the API.  Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin does it for them (parsing the XML and putting the results back into the original domain objects, or lists of them), as well as providing tag libraries to use information provided by the API.

This works GREAT, as long as App 2 (the API consumer) does not have its own database.  If it does, then the tables are created for those shared classes.  

Is there a way I can prevent App 2 from creating those tables?

Thanks,
Dale

[MikeHugo]

If I'm reading it correctly, just remove the dbCreate from DataSource.groovy for app2.  Then it won't try to do anything with creating DB tables...

Mike

On Tue, Nov 3, 2009 at 7:45 AM, dalew75 <nabble@...> wrote:

I'm using the idea of sharing domain classes in a plugin like this:

1) App 1 is a source of data, having a database, and providing an API to
access its data.
2) App 2 wants to use that API, but so does App 3 and App 4
3) So I made a plugin that contains the domain classes from App 1.  It also
has a service class and tag library to make it easier to use the API.
Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin
does it for them (parsing the XML and putting the results back into the
original domain objects, or lists of them), as well as providing tag
libraries to use information provided by the API.

This works GREAT, as long as App 1 (the API consumer) does not have its own
database.  If it does, then the tables are created for those shared classes.

Is there a way I can prevent App 2 from creating those tables?

Thanks,
Dale
--
View this message in context: http://old.nabble.com/unique-question-about-sharing-domain-classes-in-a-plugin-tp26160125p26160125.html
Sent from the grails - user mailing list archive at Nabble.com.


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

   http://xircles.codehaus.org/manage_email

--
Mike Hugo
Piragua Consulting
http://www.piragua.com/about

Try http://WhenWorksForYou.com the next time you need to coordinate schedules with friends or colleagues!

[Fabien7474]

Hi Dale,

I don't have the direct answer to your question (I am not very familiar with plugin development). But you can take a look at the Nimble plugin. It is a plugin that creates domain classes and has access to the DB.
So basically, they should have encountered the same issue as yours.

That's my 2 cents...

dalew75 wrote:

I'm using the idea of sharing domain classes in a plugin like this:

1) App 1 is a source of data, having a database, and providing an API to access its data.
2) App 2 wants to use that API, but so does App 3 and App 4
3) So I made a plugin that contains the domain classes from App 1.  It also has a service class and tag library to make it easier to use the API.  Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin does it for them (parsing the XML and putting the results back into the original domain objects, or lists of them), as well as providing tag libraries to use information provided by the API.

This works GREAT, as long as App 2 (the API consumer) does not have its own database.  If it does, then the tables are created for those shared classes.  

Is there a way I can prevent App 2 from creating those tables?

Thanks,
Dale

[dalew75]

Fabien,

Thanks for the reply, but I don't think looking at Nimble will help answer my question.  I think installing that plugin will make your app create the tables.  I want a way for one app (the API provider) to use the plugin to define the domain objects normally (create tables), and the other app to use the plugin as a way to parse the API responses and map them back into the domain objects (but not create the tables)


Hi Dale,

I don't have the direct answer to your question (I am not very familiar with plugin development). But you can take a look at the Nimble plugin. It is a plugin that creates domain classes and has access to the DB.
So basically, they should have encountered the same issue as yours.

That's my 2 cents...

[Hubert Chang]

With App2, install App1 plugin and move the app1 plugin domain classes to plugins/app1-plugin/src/groovy/ manually.

dalew75 wrote:

I'm using the idea of sharing domain classes in a plugin like this:

1) App 1 is a source of data, having a database, and providing an API to access its data.
2) App 2 wants to use that API, but so does App 3 and App 4
3) So I made a plugin that contains the domain classes from App 1.  It also has a service class and tag library to make it easier to use the API.  Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin does it for them (parsing the XML and putting the results back into the original domain objects, or lists of them), as well as providing tag libraries to use information provided by the API.

This works GREAT, as long as App 2 (the API consumer) does not have its own database.  If it does, then the tables are created for those shared classes.  

Is there a way I can prevent App 2 from creating those tables?

Thanks,
Dale

[Hubert Chang]

With App2, install App1 plugin and move the app1 plugin domain classes to
plugins/app1-plugin/src/groovy/ manually.


dalew75 wrote:

>
> I'm using the idea of sharing domain classes in a plugin like this:
>
> 1) App 1 is a source of data, having a database, and providing an API to
> access its data.
> 2) App 2 wants to use that API, but so does App 3 and App 4
> 3) So I made a plugin that contains the domain classes from App 1.  It
> also has a service class and tag library to make it easier to use the API.
> Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin
> does it for them (parsing the XML and putting the results back into the
> original domain objects, or lists of them), as well as providing tag
> libraries to use information provided by the API.
>
> This works GREAT, as long as App 2 (the API consumer) does not have its
> own database.  If it does, then the tables are created for those shared
> classes.  
>
> Is there a way I can prevent App 2 from creating those tables?
>
> Thanks,
> Dale
>

--
View this message in context: http://old.nabble.com/unique-question-about-sharing-domain-classes-in-a-plugin-tp26160125p26160250.html
Sent from the grails - user mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email

[Hubert Chang]

With App2, install App1 plugin and move the app1 plugin domain classes to
plugins/app1-plugin/src/groovy/ manually.


dalew75 wrote:

>
> I'm using the idea of sharing domain classes in a plugin like this:
>
> 1) App 1 is a source of data, having a database, and providing an API to
> access its data.
> 2) App 2 wants to use that API, but so does App 3 and App 4
> 3) So I made a plugin that contains the domain classes from App 1.  It
> also has a service class and tag library to make it easier to use the API.
> Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin
> does it for them (parsing the XML and putting the results back into the
> original domain objects, or lists of them), as well as providing tag
> libraries to use information provided by the API.
>
> This works GREAT, as long as App 2 (the API consumer) does not have its
> own database.  If it does, then the tables are created for those shared
> classes.  
>
> Is there a way I can prevent App 2 from creating those tables?
>
> Thanks,
> Dale
>

--
View this message in context: http://old.nabble.com/unique-question-about-sharing-domain-classes-in-a-plugin-tp26160125p26160278.html
Sent from the grails - user mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email

[Hubert Chang]

With App2, install App1 plugin and move the app1 plugin domain classes to
plugins/app1-plugin/src/groovy/ manually.


dalew75 wrote:

>
> I'm using the idea of sharing domain classes in a plugin like this:
>
> 1) App 1 is a source of data, having a database, and providing an API to
> access its data.
> 2) App 2 wants to use that API, but so does App 3 and App 4
> 3) So I made a plugin that contains the domain classes from App 1.  It
> also has a service class and tag library to make it easier to use the API.
> Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin
> does it for them (parsing the XML and putting the results back into the
> original domain objects, or lists of them), as well as providing tag
> libraries to use information provided by the API.
>
> This works GREAT, as long as App 2 (the API consumer) does not have its
> own database.  If it does, then the tables are created for those shared
> classes.  
>
> Is there a way I can prevent App 2 from creating those tables?
>
> Thanks,
> Dale
>

--
View this message in context: http://old.nabble.com/unique-question-about-sharing-domain-classes-in-a-plugin-tp26160125p26160284.html
Sent from the grails - user mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email

[Hubert Chang]

With App2, install App1 plugin and move the app1 plugin domain classes to
plugins/app1-plugin/src/groovy/ manually.


dalew75 wrote:

>
> I'm using the idea of sharing domain classes in a plugin like this:
>
> 1) App 1 is a source of data, having a database, and providing an API to
> access its data.
> 2) App 2 wants to use that API, but so does App 3 and App 4
> 3) So I made a plugin that contains the domain classes from App 1.  It
> also has a service class and tag library to make it easier to use the API.
> Instead of each Apps 2-4 each doing the parsing of the XML etc, the plugin
> does it for them (parsing the XML and putting the results back into the
> original domain objects, or lists of them), as well as providing tag
> libraries to use information provided by the API.
>
> This works GREAT, as long as App 2 (the API consumer) does not have its
> own database.  If it does, then the tables are created for those shared
> classes.  
>
> Is there a way I can prevent App 2 from creating those tables?
>
> Thanks,
> Dale
>

--
View this message in context: http://old.nabble.com/unique-question-about-sharing-domain-classes-in-a-plugin-tp26160125p26160290.html
Sent from the grails - user mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email

[dalew75]

Yes, but that's not the "slick way" I want to do this.  In that case I would have to keep those files in sync.  I might as well just put those /src/groovy versions into the plugin instead.


With App2, install App1 plugin and move the app1 plugin domain classes to plugins/app1-plugin/src/groovy/ manually.

[dalew75]

Like I was saying, all is fine if app2 doesn't need its own database.  The issue is when it does.....  Then the plugin's domain classes get added alongside app2's database.


If I'm reading it correctly, just remove the dbCreate from DataSource.groovy
for app2.  Then it won't try to do anything with creating DB tables...

Mike

[Hubert Chang]

Another way is,
read a configuration variable,like config.app1.plugin.domain.omited
if it is true, then add omit set with grails-app/domain/* (or with dbcreate way)
else do nothing.
With app1, you add a line to your config.groovy:
   app1.plugin.domain.omited = true

I didn't test it.

Yes, but that's not the "slick way" I want to do this.  In that case I would have to keep those files in sync.  I might as well just put those /src/groovy versions into the plugin instead.

Hubert Chang wrote:

With App2, install App1 plugin and move the app1 plugin domain classes to plugins/app1-plugin/src/groovy/ manually.

[dalew75]

Not sure what you mean exactly, but it stills sound like this will not create any tables when that config property is false.  So app2's domain classes won't get created as tables.


Another way is,
read a configuration variable,like config.app1.plugin.domain.omited
if it is true, then add omit set with grails-app/domain/* (or with dbcreate way)
else do nothing.
With app1, you add a line to your config.groovy:
   app1.plugin.domain.omited = true

I didn't test it.

[dalew75]

The way I'm getting around this issue now is to completely remove the dbCreate property in the DataSource.groovy file once my tables are created the way I want them.  This ensures that no tables are created or modified after that point.  Of course if your data initialization process requires a plug-in that defines domain objects, you'll have to delete the tables it creates after the tables/data are created for your app.


Not sure what you mean exactly, but it stills sound like this will not create any tables when that config property is false.  So app2's domain classes won't get created as tables.

Hubert Chang wrote:

Another way is,
read a configuration variable,like config.app1.plugin.domain.omited
if it is true, then add omit set with grails-app/domain/* (or with dbcreate way)
else do nothing.
With app1, you add a line to your config.groovy:
   app1.plugin.domain.omited = true

I didn't test it.