Home/ Questions/Q 1052657
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T17:07:41+00:00

I have a Java application that uses an Apache Derby database with the embedded

  • 0

I have a Java application that uses an Apache Derby database with the embedded driver. Right now, in the installation, I run the SQL create scripts out of process.

So when the application starts up, the tables are already existing. Recently I’ve started to think it would be better to have my SQL script in the classpath or something, load it, and execute all the statements so that the tables are created upon startup. The database itself can be autocreated if missing, so this seems like it might be a less error-prone way to bootstrap the tables.

My question is: Am I likely to run into any issues with detecting existence/creating tables in process on application startup vs. expecting them to be set up properly by my install?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think your first step should be to build them during the install and fail gracefully at runtime. Then flesh out the fail gracefully part to be self-repairing.

    Detecting and handling error conditions in process is, IMO, always better than assuming (expecting) and crashing.

    I would advocate not “expecting” tables to be set up properly by the install. I’m not saying you shouldn’t set the database up during the install. What I’m advocating for is code that verifies database integrity. If you have code that verifies the existence and design of your schema and can repair/rebuild, then you don’t need to worry about whether the install set everything up properly. This doesn’t mean you shouldn’t do that creation during the install, especially if it’s slow.

    I know that a lot of the apps I develop these days have built in migrations based on app version. Basically, when the app starts up it goes through a DB validation/verification cycle, determines the state of the database, and performs associated migrations based on database version and code version.

    This requires you to be diligent with up and down migrations (or just up, if you never need to rev back) but I’ve found it to be a very slick and useful solution. Of course, you need it to be robust against multiple startups, user configuration differences, and be able to handle error situations gracefully, but that’s par for the course, in my opinion.

    • 0