geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: Loose end #2: sql scripts
Date Sat, 19 Nov 2005 06:54:57 GMT
+1 - would  be useful for ISVs who want to ship demo/evaluation 
applications that can be quickly deployed.


Matt Hogstrom wrote:

> +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 excellent.
> +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?
>>> thanks
>>> david jencks

View raw message