You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/11/18 08:15:39 UTC
Loose end #2: sql scripts
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
Re: Loose end #2: sql scripts
Posted by Dain Sundstrom <da...@iq80.com>.
+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 <da...@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
>>
>>
Re: Loose end #2: sql scripts
Posted by John Sisson <jr...@gmail.com>.
+1 - would be useful for ISVs who want to ship demo/evaluation
applications that can be quickly deployed.
John
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 <da...@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
>>>
>>>
>>
>>
>>
>
>
Re: Loose end #2: sql scripts
Posted by Matt Hogstrom <ma...@hogstrom.org>.
+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 <da...@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
>>
>>
>
>
>
Re: Loose end #2: sql scripts
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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
>
>