tlberglund / groovy-liquibase Goto Github PK
View Code? Open in Web Editor NEWYet Another Groovy DSL for Liquibase
License: Other
Yet Another Groovy DSL for Liquibase
License: Other
We want to use groovy-liquibase outside our svn. If we want to run it, it saves his filepath from where you run groovy-liquibase.
So if another developer want's to update, he has other filepaths and it will crash.
I'm now editing the code to support this.
Change working directory and let groovy-liquibase execute changelogs from the working directory
My colleague is using Windows. He did a build with gradle and had 1 test error about \ \ .
That isn't a big problem. He ran the changeset located in changelogs\changelog.groovy
But when you look in the database it deletes . So = changelogschangelog.groovy
INFO 15-3-11 16:46:liquibase: ChangeSet changelogs\changelog_1.groovy::1::erwin
ran successfully in 194ms
| 1 | erwin | changelogschangelog_1.groovy | 2011-03-15 16:46:16 |
This is really annoying I'm stuck at this point. Rollback won't work because the path.
Not all column constraints from liquibase core are in this plugin
Code of liquibase core:
public class ConstraintsConfig {
private Boolean nullable;
private Boolean primaryKey;
private String primaryKeyName;
private String primaryKeyTablespace;
private String references;
private Boolean unique;
private String uniqueConstraintName;
private String check;
private Boolean deleteCascade;
private String foreignKeyName;
private Boolean initiallyDeferred;
private Boolean deferrable;
code of plugin
constraint = new ConstraintsConfig(primaryKey: false,
unique: false,
deleteCascade: false,
initiallyDeferred: false,
deferrable: false,
nullable: true)
}
Already working on solution, adding those other constraints and testing
I'm trying to include on my root changelog an inclusion of another file.
I load the changelogs using a pattern matching Spring Resource Loader like "classpath*:migrations/rootChangelog.groovy"
(see LiquibaseGriffonAddon.groovy).
I've seen the inclusion is implemented at DatabaseChangeLogDelegate.groovy
as
new File(params.path).eachFileMatch(~/.*.groovy/) { file->
I guess that ties the script to be a regular file (from filesystem).
modifySql tag isn't supported.
It's used to add sql to a generated SQL script.
Example:
createTable(tableName: "projects"){
column(name: "id", type: "bigint(20)"){
constraints(nullable: "false", primaryKey: "true")
}
column(name: "project_name", type: "varchar(50)")
}
modifySql{
append(value: " DEFAULT CHARSET=utf8")
}
It adds default charset at the end of sql script from create table.
Other possibilities
After clean up.
Some function won't work anymore. example
gradle -q -b liquibase.gradle updateSQL -Dliquibase.count=1
And not all parameters are liquibase.?
I just upgraded the liquibase plugin from version 0.6.1 to version 0.7, which uses a newer version of the groovy-liquibase DSL. I am now get checksum errors when I try to run "gradle update". The error is with an old changeSet:
changeSet(id: '25.9.7-base-action_output-constraints', author: 'various (generated)') {
addForeignKeyConstraint(
baseColumnNames: 'Action_Output_Type_Id',
baseTableName: 'action_output', constraintName: 'FK_Action_Output_Action_Output_Type_Id',
deferrable: false,
initiallyDeferred: false,
onDelete: 'NO ACTION',
onUpdate: 'NO ACTION',
referencedColumnNames: 'Id',
referencedTableName: 'action_output_type',
referencesUniqueColumn: false)
}
The crux of the problem seems to be with that last bit. I added some logging to Liquibase's MD5Util class to see what was being passed for checksumming. In version 0.7.3 of the DSL, the referencesUniqueColumn
parameter is not passed to the checksum routine, but in 0.7.6, it is. This causes a checksum mismatch. I noticed that ChangeSetDelegate.groovy line 269 changed between these versions. What I can't quite figure out is if this is a bug introduced, or a bug fixed.
Can you help shed some light on the subject?
Steve
The behavior of the include(path: "some/path/to/changesets")
tag of dabaseChangeLog
has changed significantly since the 0.7.3 release. In the 0.7.3 release, only groovy files in the given path were included, and they were included in alphabetical order.
Release 0.7.6 Includes all files in the given directory, and in no particular order. This breaks change logs that were counting on the changesets being run in a particular order, which is how I think most people use changesets. There will also be errors if the given directory contains other files, such as backup files, documentation in text files, or even .swp files that exist if the user has a changeset file open in the editor.
There is a workaround:
databaseChangeLog {
include(path: "some/path")
}
can be replaced with
databaseChangeLog {
def filenames = []
def dirname = "src/main/db/changelogs"
new File("some/path").eachFileMatch(~/.*\.groovy/) { f ->
filenames << f
}
filenames.sort().each() { f ->
include(file: "some/path/${f.name}")
}
}
This works, but it is a bit messy and I think we should consider reverting back to the old behavior. I can submit a pull request if you agree.
Steve
Allow specific sections of a change log to be used for only one type of RDBMS. This would allow us to do things such as:
changeSet() {
createTable(tableName: "address") {
column(autoIncrement: true, name: "id", type: "BIGINT") {
constraints(nullable: false, primaryKey: true)
}
}
rdbms('hsqldb') {
sql('x')
} other {
sql('y')
}
// do something else
}
So, the following change sets would be semantically equal:
changeSet(rdbms: 'mysql') {
...
}
changeSet() {
rdbms('mysql') {
...
}
}
load data gives an error:
No file opener specified for books.csv
code
resourceAccessor opener = getResourceAccessor
result Null
I tried to use sqlFile but I keep getting an error:
Liquibase Update Failed: Unknown Reason
SEVERE 3/7/11 4:15 PM:liquibase: Unknown Reason
java.lang.NullPointerException
at liquibase.change.core.SQLFileChange.loadFromFileSystem(SQLFileChange.java:119)
at liquibase.change.core.SQLFileChange.init(SQLFileChange.java:83)
For more information, use the --logLevel flag)
at liquibase.changelog.visitor.ValidatingVisitor.visit(ValidatingVisitor.java:72)
at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:58)
at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:131)
at liquibase.Liquibase.update(Liquibase.java:110)
at liquibase.integration.commandline.Main.doMigration(Main.java:686)
at liquibase.integration.commandline.Main.main(Main.java:115)
This is the changeset:
changeSet(author: "erwin", id: "10") {
comment("dump")
sqlFile(path: "dump.sql")
}
Also tried:
changeSet(author: "erwin", id: "10") {
comment("dump")
sqlFile(path: "/home/fook/workspace/Groovy-Liquibase/dump.sql")
}
And
changeSet(author: "erwin", id: "10") {
comment("dump")
sqlFile(path: "~/workspace/Groovy-Liquibase/dump.sql",
stripComments: false, splitStatements: true, encoding: "utf8",
endDelimiter: ";")
}
And (editted changeSetDelegate sqlFile I added relativeToChangelogFile)
changeSet(author: "erwin", id: "10") {
comment("dump")
sqlFile(path: "dump.sql", relativeToChangelogFile: true,
stripComments: false, splitStatements: true, encoding: "utf8",
endDelimiter: ";")
}
None of them worked.
Whenever a file resource accessor is used with a custom base path, include statements no longer work. This is because the include parser does not use the resource accessor, but new File(params.path), which has no knowledge of our base directory.
Code (DatabaseChangeLogDelegate.groovy - line 94 ~ 101):
def files = []
new File(params.path).eachFileMatch(~/.*.groovy/) { file->
files << file.path
}
files.sort().each { filename ->
includeChangeLog(filename)
}
Some tags use relativeToChangelogFile in liquibase core.
It isn't supported in groovy-liquibase.
Now that Liquibase has released version 3.0, I think the DSL (and the gradle plugin) should support it.
I've tried building this project against Liquibase 3, but unfortunately they have changed some things in Liquibase and the build now fails.
I'm happy to help out with the coding. I've got copies of Liquibase, the grooby-liquibase DSL, and the gradle liquibase plugin. I don't know all the nuances of Liquibase itself or what is required of a DSL, so I'd need someone to collaborate with, who could point me in the right direction.
Steve
While trying to replace a primary key column in an existing table, the primary key name for my Oracle and PostgreSQL tables isn't being set (instead the default is used for each DBMS).
I first dropped the existing primary key column using dropColumn
:
dropColumn(columnName: 'foo_id', tableName: 'foo')
Then I tried to add the column using addColumn
:
addColumn(tableName: 'foo') {
column(name: 'new_foo_id', type: '${primaryKeyType}') {
constraints(primaryKey: true, primaryKeyName: 'pk_foo')
}
}
This creates the primary key, but it doesn't create the primary key name.
To get around this, I did the following:
addColumn(tableName: 'foo') {
column(name: 'new_foo_id', type: '${primaryKeyType}')
}
addPrimaryKey(columnNames: 'new_foo_id', tableName: 'foo',
constraintName: 'pk_foo')
There is now a customChange without code.
It should allow:
You could take a look at the grails plugin, he has a GrailsChange.
changeset
changeSet(author: "erwin", id: "1"){
delete(tableName: "books"){
where("id=8")
}
}
RESULT
String index out of range: -1
It works fine with gradle, but we use Maven in "42bv" so we want to have Maven support.
It will make Groovy-Liquibase, easier to adopt for projects.
I'd like to write my liquibase changelogs using this groovy-dsl, but it is not obvious whether or not it supports liquibase plugins. If it does, an example should be added to the documentation. If it does not, support should be added along with an example.
Thanks for taking a random request from a stranger.
The Grails database migration plugin already has support of Groovy DSL for changelogs.
Could you integrate and reuse your code?
Whenever using a BOOLEAN type in a column, the default value is always interpreted as TRUE. It does not happen for other types, such as BIT or TINYINT.
column(name: "createRight", type: "BOOLEAN", defaultValue: false) { constraints(nullable: false) }
generates the following output:
HSQLDB
createRight BOOLEAN DEFAULT TRUE NOT NULL
MySQL
createRight
tinyint(1) NOT NULL DEFAULT '1',
I've also tried other defaultValues such as 'false' "false" 0. All yield the same result.
When adding a classpath dependency on the ojdbc6 jar (classpath 'com.oracle:ojdbc6:11.2.0.2.0') and running updateSQL, I'm getting the following error:
"Liquibase Update Failed: Cannot find database driver: "oracle.jdbc.OracleDriver" "
Running in debug mode, I see the ojdbc jar is in the classpath. If I run with Java (taking gradle out of the picture), it finds the driver but fails trying to parse the changelog.groovy file. Running within gradle seems to be having some kind of issue with the lifecycle related to the oracle driver.
Not yet created
Now listed as modifyColumn.
Isn't modifyDataType?
The Liquibase changeset has attribute 'runAlways':
http://www.liquibase.org/manual/changeset
But current version of liquibase-dsl doesn't support this name and 'alwaysRun' has to be used instead:
https://github.com/tlberglund/groovy-liquibase/blob/master/src/main/groovy/com/augusttechgroup/liquibase/delegate/DatabaseChangeLogDelegate.groovy#L49
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 6: unexpected char: '' @ line 6, column 20. include(file: 'C:\Users\Erwin\AppData\Local\Temp\liquibase-8652829959237818445.groovy') ^ 1 error
Liquibase has an includeAll tag, it isn't possible in groovy-liquibase.
It could be make as his own method or add it to include.
IncludeAll should only read the groovy files in a directory, NOT a subdirectory.
includeAll(path: "/path/")
OR
include(path: "/path/")
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.