Groovy for Domain-specific Languages - Second Edition

(nextflipdebug2) #1
Chapter 10

[ 261 ]

A database builder


Every application that includes a database needs some means of setting up seed,
demo, or test data. I have worked on numerous enterprise applications during my
career and invariably the management of different datasets becomes as much of an
effort over time as the development of the application itself. In my own experience
of working with Independent Software Vendors (ISVs), whose applications need
to be deployed on multiple customer sites with multiple versions, the problem
becomes acute.


ISV companies often have competing needs for datasets. The sales organization
needs a predictable dataset for its demos to customers. The test department
needs datasets that allow them to test specific features of the application. Project
management requires specific seed data to be available, which is tailored to each
customer site prior to installation. With all of these competing requirements, the IT
department has a limited set of database instances available on which to install and
test all of these configurations.


There are various ways of managing datasets. The most common is to maintain
SQL scripts that take care of the database insertions. Building a simple database
will require multiple insertions into a multitude of tables. The SQL script needs to be
written in such a way as to maintain the integrity of foreign key references. It's not an
easy thing to do, and requires intimate knowledge of the schema.


Suppose we are working with a Grails application. Take for example the one-to-many
relationship we looked at in Chapter 6, Example DSL – GeeTwitter:


class Customer {
String firstName
String lastName
static hasMany = [invoices:Invoice]
}

class Invoice {
static hasMany = [orders:SalesOrder]
}

class SalesOrder {
String sku
int amount
Double price
static belongsTo = Invoice
}
Free download pdf