You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Brian Peterson <pu...@verizon.net> on 2008/12/06 18:45:40 UTC

procedure to upgrade or create an embedded database

I'm trying to figure out how to determine what connection parameters for an
embedded database I should use when there might not be a database in place
(so "create=true"), or there might be an older version already in place (so
"upgrade=true"), or there might already be a database of the right version
in place (so "create" or add nothing to the URL).

I read that "upgrade" and "create" cannot both be specified in the
connection URL. If I'm putting out a release of my application that uses the
latest version of Derby (10.4) while a previous version used 10.2.2, what
are the recommended steps for making the connection to the Derby database if
one is already present? (Note that I have to handle this programmatically as
part of the application startup.)

Do I first try a URL with "create" and see if there's an error, and if so,
follow up with a call with "upgrade"? Or do I have the procedure always use
"upgrade" and follow up with a URL with "create" if it fail to make a
connection?

Brian




Re: procedure to upgrade or create an embedded database

Posted by Rick Hillegas <Ri...@Sun.COM>.
Brian Peterson wrote:
> I'm trying to figure out how to determine what connection parameters for an
> embedded database I should use when there might not be a database in place
> (so "create=true"), or there might be an older version already in place (so
> "upgrade=true"), or there might already be a database of the right version
> in place (so "create" or add nothing to the URL).
>
> I read that "upgrade" and "create" cannot both be specified in the
> connection URL. If I'm putting out a release of my application that uses the
> latest version of Derby (10.4) while a previous version used 10.2.2, what
> are the recommended steps for making the connection to the Derby database if
> one is already present? (Note that I have to handle this programmatically as
> part of the application startup.)
>
> Do I first try a URL with "create" and see if there's an error, and if so,
> follow up with a call with "upgrade"? Or do I have the procedure always use
> "upgrade" and follow up with a URL with "create" if it fail to make a
>   
Hi Brian,

Your first approach sounds good to me:

1) Bring up the database, specifying "create=true"

2) If you get the warning that the database already exists, then bring 
down the database and reboot it in upgrade mode

Regards,
-Rick
> connection?
>
> Brian
>
>
>
>   


Re: procedure to upgrade or create an embedded database

Posted by Donald McLean <dm...@gmail.com>.
It is reasonably easy to find out if the database exists in Java -
create a File object with the correct path. If "exists()" returns
false then create it, otherwise you can upgrade it.

Donald

On Sat, Dec 6, 2008 at 12:45 PM, Brian Peterson <pu...@verizon.net> wrote:
> I'm trying to figure out how to determine what connection parameters for an
> embedded database I should use when there might not be a database in place
> (so "create=true"), or there might be an older version already in place (so
> "upgrade=true"), or there might already be a database of the right version
> in place (so "create" or add nothing to the URL).
>
> I read that "upgrade" and "create" cannot both be specified in the
> connection URL. If I'm putting out a release of my application that uses the
> latest version of Derby (10.4) while a previous version used 10.2.2, what
> are the recommended steps for making the connection to the Derby database if
> one is already present? (Note that I have to handle this programmatically as
> part of the application startup.)
>
> Do I first try a URL with "create" and see if there's an error, and if so,
> follow up with a call with "upgrade"? Or do I have the procedure always use
> "upgrade" and follow up with a URL with "create" if it fail to make a
> connection?

-------------------------------------------------------------
Family photographs are a critical legacy for
ourselves and our descendants. Protect that
legacy with a digital backup and recovery plan.