Preventing autobase migrations from running in a 'grails test-app' execution?
mbjarland
I'm running around 30 migrations with preconditions in my current
project. All the migrations work fine in the 'development' and
'production' environments as the underlying database is a legacy MySql
and all the mappings work. However, when I test the app I want to do
in memory 'create-drop' database configuration which in turn causes
the autobase migrations to break.
Is it possible to limit the migrations to specific environments? I
want to run the migrations in dev and prod, but not in test as they
don't make any sense in a 'create-drop' domain model generated
schema.
Best,
Matias Bjarland
Robert Fischer
migrations when executing in create-drop mode. That's not a bad idea.
Please open a ticket over at http://jira.codehaus.org/browse/GRAILSPLUGINS/component/13540
~~ Robert Fischer.
Grails Training http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog
Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html
mbjarland
mbjarland
Looking at the 'preconditions' section of the liquibase manual at:
http://www.liquibase.org/manual/preconditions
it would seem that in the original liquibase xml it is possible to
have preconditions directly under the 'databaseChangeLog' element. If
this was possible in autobase it would essentially solve my problem.
We could then do somthing like:
------ ./migrations/changelog.groovy ------
// The overall database change log
databaseChangeLog(logicalFilePath:'mrgrails-autobase') {
preConditions {
//Since we use hsqldb in the 'test' environment, this line should
prevent
//the migrations from being run under 'grails test-app'
dbms(type:'mysql')
}
includeAll('./migrations')
}
There are also other preconditions that might be used to disable
execution of the migrations such as the 'runningAs' precondition.
Unfortunately it seems that either I'm doing something borked, or the
databaseChangeLog method in the autobase dsl does not support
preConditions. Console log with stack trace from executing "grails
test-app" with the above changelog.groovy under autobase 0.7 can be
found here:
http://grails-autobase.googlegroups.com/web/ConsoleLog_PreconditionsOnDatabaseChangeLogElement.txt?gsc=BYi4QQsAAABy7rzJ_szcRhwvu-X5Wsvk
Any thoughts?
Best,
Matias
On Feb 25, 9:55 am, mbjarland <mbjarl...@gmail.com> wrote:
> Created a ticket athttp://jira.codehaus.org/browse/GRAILSPLUGINS-933
>
> -Matias
Robert Fischer
time, and I seem to recall writing a bit of code around that. I'll take a look and see where I left it.
~~ Robert.
mbjarland
(and git apparently not being all that friendly with windows) I
wouldn't mind contributing if needed.
If we were to get preconditions working on the databaseChangeLog node,
an elegant way of solving the initial problem of preventing migrations
from running under certain conditions would be to write a custom
precondition "dbCreateSetting(mode:'update')". Since we already have
boolean operators for the preconditions, this would enable us to do
"not { dbCreateSetting(mode: 'create-drop') }" or:
or {
dbCreateSetting(mode: 'update')
dbCreateSetting(mode: 'create')
}
etc. Just a thought...
Oh and while I'm at it, a couple of questions:
1. What subset of the grails application/configuration/etc objects do
we have access to from the context of the executing changelog
scripts?
2. A somewhat fuzzy one...isn't exactly crystal in my mind yet, but
here goes. What is the contract between the liquibase dsl artifacts
and general groovy code. For example, if I were to write a
file.eachFileRecurse { f -->
include(<somefunctionof_f> + "myMigration.groovy)
...
}
would that work? Same for migrations and especially for preconditions.
I would for example want to be able to do a precondition which loops
over a set of table names and checks for existense of a specific
column on any one of them.
Also, not sure if I'll have the time, but would you mind if I started
a new page with example usages for all the liquibase refactorings in
autobase dsl on your github wiki. Not sure if I'd go as far as call it
a reference, but some more detail wouldn't hurt. Seems like you get a
boatload of questions on syntax and I think a few extra pages might
lower the barrier of entry.
Best,
Matias
On Feb 25, 5:04 pm, Robert Fischer <robert.fisc...@smokejumperit.com>
wrote:
> > Any thoughts?
>
> > Best,
> > Matias
>
> > On Feb 25, 9:55 am, mbjarland <mbjarl...@gmail.com> wrote:
> >> Created a ticket athttp://jira.codehaus.org/browse/GRAILSPLUGINS-933
>
> >> -Matias
>
> --
> ~~ Robert Fischer.
> Grails Training http://GroovyMag.com/training
> Smokejumper Consultinghttp://SmokejumperIT.com
Robert Fischer
> (and git apparently not being all that friendly with windows) I
> wouldn't mind contributing if needed.
>
me again and I'll have a bit more free-time to dedicate to Autobase. I'll pitch an e-mail out to
the list when I get started.
> If we were to get preconditions working on the databaseChangeLog node,
> an elegant way of solving the initial problem of preventing migrations
> from running under certain conditions would be to write a custom
> precondition "dbCreateSetting(mode:'update')". Since we already have
> boolean operators for the preconditions, this would enable us to do
> "not { dbCreateSetting(mode: 'create-drop') }" or:
>
> or {
> dbCreateSetting(mode: 'update')
> dbCreateSetting(mode: 'create')
> }
>
> etc. Just a thought...
>
That's a good idea. There's a number of these kinds of Grails-specific preconditions that I'd like
to get out there -- domainHasProperty and grailsEnv are the two topping my list.
> Oh and while I'm at it, a couple of questions:
>
> 1. What subset of the grails application/configuration/etc objects do
> we have access to from the context of the executing changelog
> scripts?
>
I documented that...somewhere...
Not on the wiki. Crap.
I'll have to research that for you and get back to you.
> 2. A somewhat fuzzy one...isn't exactly crystal in my mind yet, but
> here goes. What is the contract between the liquibase dsl artifacts
> and general groovy code. For example, if I were to write a
>
> file.eachFileRecurse { f -->
> include(<somefunctionof_f> + "myMigration.groovy)
> ...
> }
>
> would that work? Same for migrations and especially for preconditions.
> I would for example want to be able to do a precondition which loops
> over a set of table names and checks for existense of a specific
> column on any one of them.
>
Yes, that would work.
That I *did* do some documentation on:
http://wiki.github.com/RobertFischer/autobase/groovy-in-migration-files
Be aware that if you produce a distinct change set compared to a previous run, Liquibase will
attempt to apply the change set again in a fit of helpfulness.
> Also, not sure if I'll have the time, but would you mind if I started
> a new page with example usages for all the liquibase refactorings in
> autobase dsl on your github wiki. Not sure if I'd go as far as call it
> a reference, but some more detail wouldn't hurt. Seems like you get a
> boatload of questions on syntax and I think a few extra pages might
> lower the barrier of entry.
>
Please do.
~~ Robert Fischer.
Grails Training http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog