Question

Using Grails database-migration I have a table in production defined like so:

+--------------+------------+------+-----+---------+----------------+
| Field        | Type       | Null | Key | Default | Extra          |
+--------------+------------+------+-----+---------+----------------+
| id           | bigint(20) | NO   | PRI | NULL    | auto_increment |
| version      | bigint(20) | NO   |     | NULL    |                |
| basket_id    | bigint(20) | NO   | MUL | NULL    |                |
| gift_card_id | bigint(20) | NO   | MUL | NULL    |                |
+--------------+------------+------+-----+---------+----------------+

In the latest develop branch we’ve modified this domain to use a composite key and remove the id and version:

class BasketGiftCard implements Serializable {

  Basket basket
  GiftCard giftCard

  static mapping = {
    id composite: ['basket', 'giftCard']
    version false
  }
}

When running the dbm-gorm-diff we end up with the following:

changeSet(author: "gdboling (generated)", id: "1340670757336-8") {
    addPrimaryKey(columnNames: "basket_id, gift_card_id", constraintName: "basket_gift_cPK", tableName: "basket_gift_card")
}

changeSet(author: "gdboling (generated)", id: "1340670757336-16") {
    dropPrimaryKey(tableName: "basket_gift_card")
}

changeSet(author: "gdboling (generated)", id: "1340670757336-188") {
    dropColumn(columnName: "id", tableName: "basket_gift_card")
}

changeSet(author: "gdboling (generated)", id: "1340670757336-189") {
  dropColumn(columnName: "version", tableName: "basket_gift_card")
}

What’s interesting (and wrong) about this is the order. The dropPrimaryKey should go first, then everything else. As is, when running dbm-update, it fails.

Answer 1

You have come across one of the problems with database diffs, albeit slightly different than the example given in that post. The migration plugin documentation was definitely not joking when it said:

When running migration scripts on non-development databases, it’s important that you backup the database before running the migration in case anything goes wrong. You could also make a copy of the database and run the script against that, and if there’s a problem the real database will be unaffected.

There have been several times that I needed to make manual adjustments to changelogs that were generated with dbm-gorm-diff. I think it just comes with the territory, unfortunately. That’s not to take anything away from the plugin though; it’s not perfect but I feel a lot more confident about my database structure since I started using it.