0

I'm new to pom files and new to stackoverflow.

As part of our Integration Test process I'm dropping and recreating mysql databases on each run in order to ensure clean known reference data as a starting point. This is being done via pom files which use the sql-maven-plugin and a dependency on mysql-connector-java. This is working well except for data which is originally stored as 'blob' or 'longblob' format. In these cases data is being inserted into the correct table/column but it is corrupt data.

The insert is handled via sql files which have bee created from mysqldump of a master set of databases.

If I pipe the sql files into the database using zcat or mysql then all works well and the data is created correctly, so I'm of the opinion there's nothing wrong with the sql statements created by mysqldump themselves.

Tried various different settings for "encoding" but these either fail completely or make no difference.

I'm pretty sure I must be missing something simple but I don't know what!

Extract from my pom file:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>sql-maven-plugin</artifactId>
    <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.36</version>
        </dependency>
    </dependencies>
    <configuration>
        <driver>${integration.jdbc.driver}</driver>
        <username>${integration.jdbc.super.username}</username>
        <password>${integration.jdbc.super.password}</password>
        <enableBlockMode>false</enableBlockMode>
    </configuration>
    <executions>
        <execution>
            <id>Clean old databases and create fresh ones</id>
            <phase>pre-integration-test</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <autocommit>true</autocommit>
                <forceMojoExecution>true</forceMojoExecution>
                <url>${integration.jdbc.url}</url>
                <sqlCommand>
                    drop database if exists ${integration.app.reposdb.name};
                    create database ${integration.app.reposdb.name};
                </sqlCommand>
            </configuration>
        </execution>
        <execution>
            <id>Apply grants to databases to allow non-privileged access</id>
            <phase>pre-integration-test</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <autocommit>true</autocommit>
                <forceMojoExecution>true</forceMojoExecution>
                <url>${integration.jdbc.url}</url>
                <sqlCommand>
                    grant all on ${integration.app.reposdb.name}.* to '${integration.jdbc.username}'@'%' identified by '${integration.jdbc.password}';
                    grant select,usage on ${integration.app.reposdb.name}.* to '${integration.jdbc.ro_username}'@'%' identified by '${integration.jdbc.ro_password}';
                </sqlCommand>
            </configuration>
        </execution>

        <execution>
            <id>Create application file repository db</id>
            <phase>pre-integration-test</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <autocommit>true</autocommit>
                <forceMojoExecution>true</forceMojoExecution>
                <url>${integration.jdbc.app_repos_url}</url>
                <orderFile>ascending</orderFile>
                <encoding>UTF-8</encoding>
                <fileset>
                    <basedir>${integration.release.data.snapshots}/${data.version}</basedir>
                    <includes>
                        <include>ifv2_repos.sql</include>
                    </includes>
                </fileset>
            </configuration>
        </execution>
...

Are there any obvious properties I should be setting but haven't? Is there a general issue with handling blob data through jdbc?

Tunaki
  • 132,869
  • 46
  • 340
  • 423
S Scott
  • 1
  • 1

0 Answers0