[
https://issues.apache.org/jira/browse/AIRAVATA-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17112355#comment-17112355
]
Marcus Christie commented on AIRAVATA-3326:
-------------------------------------------
I'm running into an old problem that I can't figure out how to specify
(probably it isn't possible) the persistence unit to MappingTool, so it ends up
picking the first one, which is app_catalog. I could create separate
persistence files for each persistence unit, but that would lead to code
duplication.
> Improved database migration script creation
> -------------------------------------------
>
> Key: AIRAVATA-3326
> URL: https://issues.apache.org/jira/browse/AIRAVATA-3326
> Project: Airavata
> Issue Type: New Feature
> Components: Registry API
> Reporter: Marcus Christie
> Assignee: Marcus Christie
> Priority: Major
>
> Improve automatic generation of database migration scripts. Work on this was
> started in AIRAVATA-3126. In that issue the OpenJPA MappingTool was
> integrated to run and generate a migration script whenever the schema
> validation fails.
> Continuing on that work, I'd like to
> - create a migration script generation tool (MappingTool) that can be run
> directly from the command line
> - integrate starting a MariaDB, perhaps via docker-compose, and run
> MappingTool against that to generate the mysql scripts
> -- use https://github.com/dkanejs/docker-compose-maven-plugin to have maven
> run
> docker-compose. The command would end up being something like so:
> {noformat}
> mvn docker-compose:up exec:exec@generate-migrations docker-compose:down
> {noformat}
> - finish the documentation on how to take the generated scripts and integrate
> them in the various places in the code base where they belong
> - change ide-migration docker-compose database server to mariadb. MariaDB has
> some good additions to mysql for creating migration scripts that can be
> re-runnable (e.g., {{IF NOT EXISTS}}).
> - clean up remove generate-sql-persistence.xml and maven goal that used it
> Questions
> - when there are new/changed tables in more than one schema, what migration
> script gets created? I'm guessing that they will clobber each other so the
> name of the file needs to be unique to the schema.
> h5. TODO
> - [x] Run derby db and migration script creation in ./target directory
> - [x] derby db not shutting down cleanly?
> - [ ] run MappingTool directly, don't bother too much with checking if it
> validates, just run it
> -- maybe run it in a {{finally}} block?
> - [ ] generate schema for all of the registry databases
> - [ ] separate logging configuration from test logging and separate
> airavata-server.properties files (one for derby and one for MariaDB)
> - [ ] have a mode to generate the entire schema and another mode to generate
> a migration script
> - [ ] integrate running MariaDB via Docker and generating migration scripts
> for that
> - [ ] update documentation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
