db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damian Carey" <jami...@gmail.com>
Subject Re: How to get a Derby schema.sql so we can build the next DB?
Date Thu, 18 Dec 2008 01:45:20 GMT
> On Wed, Dec 17, 2008 at 7:24 PM, Damian Carey <jamianb@gmail.com> wrote:
>> Hi all,
>> We're long term Java-Desktop-App-via-Hibernate-On-Postgres users
>> trying to transition to Derby.
>> When we deploy a new site we want to be able to (1) create the fresh
>> database then (2) "run" schema.sql to construct the database schema,
>> prior to (3) running the app and adding the data.
>> With postgres we extract the schema.sql from an existing database
>> (using pgAdminIII or whatever) and pump that raw SQL into the new
>> database. Easy and 100% reliable.
>> However, with Derby, I'm not sure how to get that SQL level snapshot
>> of an existing schema that we can use.
>> I can get the DDL from dblook, but I can't pump in DDL.  I really
>> don't want to add DdlUtils etc to our distribution.
>> So
>> (1) How do you get the raw SQL??
>> (2) What else would you suggest for transferring a schema from one
>> DerbyDB to a new fresh DerbyDB?
>> Any suggestions or advice would be greatly appreciated.
>> Many thanks,
>> -Damian
>On Thu, Dec 18, 2008 at 12:32 PM, Sai Pullabhotla <sai.pullabhotla@jmethods.com>
> Why not just copy the whole database folder from the source system to target?
> Sai Pullabhotla


Thanks for your response!

There is no problem doing that on one machine, but the idea here is to
distribute our app to hundreds or thousands of our customers, each
with their own on-site database. As they use the app for the first
time the new database is created and it's added. The schema.sql is
perhaps 20K, but the empty database is perhaps 2MB.

So I'm looking for a way to get the SQL so that we can create the
database on the fly for each new customer.
We currently also use that "SQL-on-startup" to modify the schema from
time to time.  It works like a charm with our Postgres infrastructure,
but I'm not sure how best to retain those capabilities with Derby.


View raw message