geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Loose end #2: sql scripts
Date Fri, 18 Nov 2005 19:28:08 GMT
+1 to both ideas.  For production deployments the DBAs generally don't allow 
servers or applications to arbitrarily create databases and tables.  For 
development / testing this is an improvement that with an opt-in flag would be 

+1 to both

Aaron Mulder wrote:
> My only concern is that executing SQL scripts not be the default
> behavior for an application.  As a developer I generally prefer to be
> the master of the SQL and not have the server doing things for me, and
> I think that's especially important as you look at non-developer uses.
>  But if we have a flag the user can set in their plan to automatically
> execute some SQL, or if the routine is that you add a canned
> SQL-Executor GBean definition to your plan and just point it at the
> SQL script and database pool, that's fine with me (because you have to
> do something to turn it on).  It does sound like a handy feature if
> you're into that kind of thing.  :)
> Thanks,
>     Aaron
> On 11/18/05, David Jencks <> wrote:
>>Sometimes an application needs some database tables in order to run.
>>We don't have much support for helping with this.  We have the juddi
>>server, with a script that is run from jelly code in modules/assembly,
>>and we have some work to generate scripts for cmp entity beans, but no
>>automated way of creating the tables when the app is deployed.
>>I would prefer that we find a way to package the sql with the app that
>>needs it.  One possibility is to write a gbean that will, using a
>>datasource deployed in geronimo, do some sort of test to see if the
>>script should be run, and if so execute statements from a script.  I
>>would think this would be fairly simple to write.
>>Can anyone see any problems with this idea?  Does it seem like a good
>>idea?  Is there a better way to do this?
>>david jencks

View raw message