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 <[EMAIL PROTECTED]> 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
>
>
