Database Migration Plugin

dbm-update does not work for changelog.xml (but does for changelog.groovy)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: Grails-Database-Migration 1.0
  • Fix Version/s: None
  • Labels:
    None
  • Environment:
    $ cat application.properties
    #Grails Metadata file
    #Thu Mar 01 17:45:14 EST 2012
    app.grails.version=2.0.1
    app.name=test
    app.servlet.version=2.5
    app.version=0.1
    plugins.database-migration=1.0

Description

Steps to reproduce:

$ grails create-app test
$ cd test
$ grails install-plugin database-migration
$ grails create-domain-class org.example.Book
$ grails compile
$ grails dbm-generate-gorm-changelog changelog.xml

Enable persistent (non in-memory) DB such as MySQL without a dbCreate property:

environments {
    development {
        dataSource {
            driverClassName = 'com.mysql.jdbc.Driver'
            username = 'username'
            password = 'password'
            dialect = org.hibernate.dialect.MySQL5InnoDBDialect
            url = 'jdbc:mysql://localhost/test'
        }
}

$ grails dbm-update
$ mysql test -e "show tables"
+-----------------------+
| Tables_in_test        |
+-----------------------+
| databasechangeloglock |
+-----------------------+

$ grails dbm-generate-gorm-changelog changelog.groovy
$ grails dbm-update
$ mysql test -e "show tables"
+-----------------------+
| Tables_in_test        |
+-----------------------+
| book                  |
| databasechangelog     |
| databasechangeloglock |
+-----------------------+

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Sam Gendler added a comment -

Just went through a lot of effort to set up changelogs in xml, but they still don't work - using grails 2.0.3 and database-migration plugin version 1.0. This strikes me as being of higher priority than Major, since changing to the groovy DSL makes the ability to update a database dependent on grails and we have many apps that don't run in grails, so it is important to preserve liquibase compatibility by sticking to XML. Considering that the docs certainly imply that this should work, I don't see how this is anything but a blocker bug since it makes the plugin entirely unusable. For what it is worth, running 'grails package' and then un-jarring the generated war file, it is clear that it simply isn't packaging the xml files up with the app - they are nowhere to be found in the resulting war file - likely as not, this is the reason for the failure to function - there is no changelog in the app once it is running.

Show
Sam Gendler added a comment - Just went through a lot of effort to set up changelogs in xml, but they still don't work - using grails 2.0.3 and database-migration plugin version 1.0. This strikes me as being of higher priority than Major, since changing to the groovy DSL makes the ability to update a database dependent on grails and we have many apps that don't run in grails, so it is important to preserve liquibase compatibility by sticking to XML. Considering that the docs certainly imply that this should work, I don't see how this is anything but a blocker bug since it makes the plugin entirely unusable. For what it is worth, running 'grails package' and then un-jarring the generated war file, it is clear that it simply isn't packaging the xml files up with the app - they are nowhere to be found in the resulting war file - likely as not, this is the reason for the failure to function - there is no changelog in the app once it is running.
Hide
Permalink
Ryan Vanderwerf added a comment -

running into same issue on oracle 10g here, grails 2.0.3. Changelog XML format seems to be totally broken.

Show
Ryan Vanderwerf added a comment - running into same issue on oracle 10g here, grails 2.0.3. Changelog XML format seems to be totally broken.
Hide
Permalink
Sam Gendler added a comment -

Apparently, this is just incredibly low priority. This jira exists and I have asked about it several times in the mailing list and have yet to receive any kind of response from anyone.

Show
Sam Gendler added a comment - Apparently, this is just incredibly low priority. This jira exists and I have asked about it several times in the mailing list and have yet to receive any kind of response from anyone.
Hide
Permalink
Burt Beckwith added a comment -

The default changelog name is changelog.groovy, so if you generate a changelog.xml you need to set the config attribute to tell the plugin that:

grails.plugin.databasemigration.changelogFileName = 'changelog.xml'
Show
Burt Beckwith added a comment - The default changelog name is changelog.groovy, so if you generate a changelog.xml you need to set the config attribute to tell the plugin that: grails.plugin.databasemigration.changelogFileName = 'changelog.xml'
Hide
Permalink
Sam Gendler added a comment -

DId you actually test anything before you closed this bug, because I certainly modified the changelogFileName, but it still didn't actually work. More to the point, constructing a war doesn't include the xml files but does include the groovy files, etc. changelog.xml wouldn't work, even if it obeyed rthe changelogFileName since the file wouldn't be there. But it doesn't matter, because even if I manually include the changelog.xml files into the war, it still doesn't actually do anything.

My COnfig.groovy contains both of these lines, and I've tried every possible variation of them, too, all to no avail:

grails.plugin.databasemigration.changelogLocation = "grails-app/migrations"
grails.plugin.databasemigration.changelogFileName = "changelog.xml"

I tried leaving changelogLocation out, but specifying a full path in changelogFileName
I tried various changelogLocations.
I tried a variety of xml file names.

This IS a bug

Show
Sam Gendler added a comment - DId you actually test anything before you closed this bug, because I certainly modified the changelogFileName, but it still didn't actually work. More to the point, constructing a war doesn't include the xml files but does include the groovy files, etc. changelog.xml wouldn't work, even if it obeyed rthe changelogFileName since the file wouldn't be there. But it doesn't matter, because even if I manually include the changelog.xml files into the war, it still doesn't actually do anything. My COnfig.groovy contains both of these lines, and I've tried every possible variation of them, too, all to no avail: grails.plugin.databasemigration.changelogLocation = "grails-app/migrations" grails.plugin.databasemigration.changelogFileName = "changelog.xml" I tried leaving changelogLocation out, but specifying a full path in changelogFileName I tried various changelogLocations. I tried a variety of xml file names. This IS a bug
Hide
Permalink
Burt Beckwith added a comment -

The new 2.0 console compressed output is hiding the error; try running

grails dbm-update --stacktrace --verbose

This works for me in a 2.0.0, 2.0.1, and 1.3.7 app, with and without redundantly setting changelogLocation to the default value.

p.s. try being less of a jerk; you'll find people more willing to help when you're not being rude and antagonistic

Show
Burt Beckwith added a comment - The new 2.0 console compressed output is hiding the error; try running grails dbm-update --stacktrace --verbose This works for me in a 2.0.0, 2.0.1, and 1.3.7 app, with and without redundantly setting changelogLocation to the default value. p.s. try being less of a jerk; you'll find people more willing to help when you're not being rude and antagonistic
Hide
Permalink
Sam Gendler added a comment -

Frankly, I'd be less of a jerk if I hadn't experienced 'Major' bugs in grails being left unacknowledged for, literally, years, then finally addressed only with "feel free to contribute code." And if other bugs weren't summarily closed without any actual assistance with the problem after several months of being ignored and if the same issue wasn't also ignored on the mailing list. It gets more than a little frustrating when I mostly see people having to answer their own questions over the course of many days on the mailing list, or grails neophytes, such as myself, trying to help other grails neophytes on the list since responses from anyone with actual grails experience are few and far between when issues arise which require more than a 1-liner response. This bug has been open since early March (and isn't even the only one related to this issue, never mind the variety of mailing list questions about it that have also arisen), yet the very first time it was addressed, it was to simply close as not a bug with no useful feedback.

Speaking of being rude and antagonistic - why not respond to the jira with a question, asking if those affected have tried the changelogFileName 'fix' so that you might have an opportunity to suggest the --verbose solution PRIOR to closing the bug, so that those of us who did actually read the docs and had already tried the thing that is highlighted in yellow on the first page of the docs don't feel like our issue has been dismissed summarily and without anything resembling an actual solution? Sure, a back and forth dialog about previously attempted solutions might be more appropriate on the mailing list, but since the issue was ignored there, we wound up here on jira.

And if it really does come down to the fact that the thing fails COMPLETELY SILENTLY because of an error, how is that even remotely useful? Why would the default be to make no mention whatsoever of an error so catastrophic as to prevent any and all functionality from completing? I can see not dumping hundreds of lines of stacktrace by default, but simply exiting with no indication that a catastrophic error even occurred is, frankly, a bug in and of itself. It's not as though failing to create/update the database is a recoverable error that can be safely ignored. No one who hasn't already encountered grails apparent propensity for completely swallowing catastrophic errors would think that they'd have to specify a --verbose option to even be informed of the existence of a catastrophic error, let alone the details of what occurred. At the very least, the plugin should include documentation that says something like "warning: if the dbm plugin encounters an error, you will NOT be informed of it unless you run grails with the --verbose option"

Not only did I lose a solid 12 hours of development time to grails' apparent unwillingness to tell me of a catastrophic error, but I also lost a ton of productivity for an entire team when I gave up on the dbm plugin until such time as I had a chance to dig into the source code for myself, since there was no assistance available from the community whatsoever. I asked on the list and I contributed to a jira, yet it took 2 months to get the very first acknowledgement of the issue, which was simply to summarily close it. Of course that ticked me off, and it showed in my response.

Show
Sam Gendler added a comment - Frankly, I'd be less of a jerk if I hadn't experienced 'Major' bugs in grails being left unacknowledged for, literally, years, then finally addressed only with "feel free to contribute code." And if other bugs weren't summarily closed without any actual assistance with the problem after several months of being ignored and if the same issue wasn't also ignored on the mailing list. It gets more than a little frustrating when I mostly see people having to answer their own questions over the course of many days on the mailing list, or grails neophytes, such as myself, trying to help other grails neophytes on the list since responses from anyone with actual grails experience are few and far between when issues arise which require more than a 1-liner response. This bug has been open since early March (and isn't even the only one related to this issue, never mind the variety of mailing list questions about it that have also arisen), yet the very first time it was addressed, it was to simply close as not a bug with no useful feedback. Speaking of being rude and antagonistic - why not respond to the jira with a question, asking if those affected have tried the changelogFileName 'fix' so that you might have an opportunity to suggest the --verbose solution PRIOR to closing the bug, so that those of us who did actually read the docs and had already tried the thing that is highlighted in yellow on the first page of the docs don't feel like our issue has been dismissed summarily and without anything resembling an actual solution? Sure, a back and forth dialog about previously attempted solutions might be more appropriate on the mailing list, but since the issue was ignored there, we wound up here on jira. And if it really does come down to the fact that the thing fails COMPLETELY SILENTLY because of an error, how is that even remotely useful? Why would the default be to make no mention whatsoever of an error so catastrophic as to prevent any and all functionality from completing? I can see not dumping hundreds of lines of stacktrace by default, but simply exiting with no indication that a catastrophic error even occurred is, frankly, a bug in and of itself. It's not as though failing to create/update the database is a recoverable error that can be safely ignored. No one who hasn't already encountered grails apparent propensity for completely swallowing catastrophic errors would think that they'd have to specify a --verbose option to even be informed of the existence of a catastrophic error, let alone the details of what occurred. At the very least, the plugin should include documentation that says something like "warning: if the dbm plugin encounters an error, you will NOT be informed of it unless you run grails with the --verbose option" Not only did I lose a solid 12 hours of development time to grails' apparent unwillingness to tell me of a catastrophic error, but I also lost a ton of productivity for an entire team when I gave up on the dbm plugin until such time as I had a chance to dig into the source code for myself, since there was no assistance available from the community whatsoever. I asked on the list and I contributed to a jira, yet it took 2 months to get the very first acknowledgement of the issue, which was simply to summarily close it. Of course that ticked me off, and it showed in my response.

People

  • Assignee:
    Burt Beckwith
    Reporter:
    Rob Light
Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: