geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Loose end #2: sql scripts
Date Fri, 18 Nov 2005 16:54:48 GMT
+1 good idea david

+1 add an opt-in flag

-dain

On Nov 17, 2005, at 11:25 PM, 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 <david_jencks@yahoo.com> 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
>>
>>


Mime
View raw message