Comments on: Seeking an Agile Database Definition Language

By: Jim

Jim — Sat, 01 Mar 2008 20:03:54 +0000

Hand code SQL scripts for each db vendor and make sure you have solid persistence layer abstraction. It’s the only way to handle these kinds of requirement’s in agile, production environments.

By: eliteab » Blog Archive » Seeking an Agile Database Definition Language

eliteab » Blog Archive » Seeking an Agile Database Definition Language — Mon, 22 Oct 2007 08:08:43 +0000

[...] check the full story here [...]

By: Geoffrey Wiseman

Geoffrey Wiseman — Mon, 18 Jun 2007 01:52:16 +0000

Liquibase looks like it might be headed in the direction of something you’d be interested in, but I don’t think it’s quite where you need it to be yet (data insertions, for instance). Might be worth a look.

By: Stefan Tilkov

Stefan Tilkov — Sat, 16 Jun 2007 19:41:57 +0000

I second the idea of using Rails migrations; should have thought of that myself. Combined with JRuby, you have perfect integration.

By: Kenneth Downs

Kenneth Downs — Sat, 16 Jun 2007 13:49:27 +0000

To clarify about YAML and Andromeda.

YAML parsers are available in just about every language out there. You can use YAML as a human-writable file format and then parse it in any language.

As far as Andromeda’s syntax is concerned, what we have defined is little more than a set of keywords that we use to specify database builds. Using YAML does not mean you have to use our keywords, especially if you are not using our parser.

I cannot help but to comment on one thing though. Look deeper at Andromeda. You are recapitulating the course that led to its development, and you will find it anticipates your needs one after the other. After you get the format down, you need a builder. Andromeda has that. After you get it built, you need an upgrader. Andromeda has that. After you can build and upgrade you will want to publish the app. Andromeda has that. Then you may wish to host multiple versions of the same app on a server. Andromeda has that. You will need a rational way to store application-level and instance-level code. Andromeda has that. You will then want to document the database structure. Andromeda has that. And so on and so on.

End of commercial :)

By: Ted Beckett

Ted Beckett — Sat, 16 Jun 2007 02:54:12 +0000

The problem I experienced with dbunit is the dataset files loaded by dbunit to set up a test are hard to read as far as understanding the explicit test conditions being set up. I’ve had more success setting up the database by writing code that uses the objects that the application uses to interface with the database. The unit tests are more readable that way.

I’m sure there is a place for dbunit. Maybe someone could explain where they found it useful in a context where the quality and readability of the unit tests are stressed?

By: Paul King

Paul King — Fri, 15 Jun 2007 22:49:56 +0000

I use either Ant’s sql task or sqlunit (which we also normally use from ant). Both mix happily with Groovy’s AntBuilder if you want the ability to refactor to reduce duplication. Both also happily mix with WebTest for functional testing of HTML and Web Service applications (in either XML/Groovy form). This allows you for example to populate the test database with data or test some database preconditions, then run a web test, then clear away the test data in the database or check some database postcondition.

I am a fan of the Groovy flavored tests myself as they tend to be faster to write and run than the XML variants and tend to be much clearer and succinct thanks to Groovy’s nifty syntax abbreviations and DSL capabilities.

By: Bill Goggin

Bill Goggin — Fri, 15 Jun 2007 18:52:55 +0000

If you’d consider perl, the DBIx::Class module team is working on supporting diffs between versions of a database with the ability to move data from the old schema to the new. Check out the 6/12/2007 perlcast podcast, http://www.perlcast.com.

By: Andrew Thompson (lordpixel)

Andrew Thompson (lordpixel) — Fri, 15 Jun 2007 14:08:08 +0000

Elliotte - just to be 100% clear, in the past I’ve been able to load SQL scripts with executeBatch(), i.e. something like

insert into foo values (…);
select from foo where …;
update bar set …;

Now it could just be an artifact of the driver I was using but as long as I used the right statement separator (in this case ‘;’) between the statements I was able to pass in a whole file in one go. Now I’m looking at the API again, I wonder if I even used addBatch() and executeBatch() at all, or whether I just passed the whole script to execute() as one big string…

I don’t know if JDBC requires this behavior work, or if it defines a standard statement separator or if that is vendor specific, but I do know it worked on the database I was using a couple of years ago.

And failing that, something that read a file line by line and called addBatch() for each line in the file would be about 30 seconds work for the guy who wrote Java I/O :)

By: Lorenzo Gatti

Lorenzo Gatti — Fri, 15 Jun 2007 08:43:51 +0000

I’m rather happy with the Oracle command line SQL*PLUS (not its ugly quasi-gui relative with the same name). After you define an alias for connection parameters you can simply call

sqlplus user/password@alias @myscript

to run myscript.sql, which can be automatically generated and can be a container that calls other scripts (some of which can be fixed or generated in different ways).
Similar command line tools doubtless exist for other DBMSs and are easily scriptable from Java (JUnit), Ant, Python, etc.

For production environments, the scripts can be regenerated with some controlled differences like switching names and omitting INSERTs of read only test data; DB administrators can easily review, edit and execute pure SQL code without interacting with the code generation and configuration control tools and procdures that originated them.