[
https://issues.apache.org/jira/browse/AIRAVATA-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Christie updated AIRAVATA-3326:
--------------------------------------
Description:
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
- [ ] refactor schema migration generation code to common so that it can be
used in sharing catalog and credential store, etc.
- [ ] undo the changes to JPAUtils.java to automatically run schema migration
generation when schema fails to validate
h5. Issues
- Schema generation generates PRIMARY KEY for table VIEWs
-- maybe use createQuery or createNativeQuery instead?
(https://coderanch.com/t/591607/databases/Mapping-JPA-Entity-View)
- Can create additive schema migrations but not ones that remove columns/tables
was:
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
h5. Issues
- Schema generation generates PRIMARY KEY for table VIEWs
-- maybe use createQuery or createNativeQuery instead?
(https://coderanch.com/t/591607/databases/Mapping-JPA-Entity-View)
> 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
> - [ ] refactor schema migration generation code to common so that it can be
> used in sharing catalog and credential store, etc.
> - [ ] undo the changes to JPAUtils.java to automatically run schema migration
> generation when schema fails to validate
> h5. Issues
> - Schema generation generates PRIMARY KEY for table VIEWs
> -- maybe use createQuery or createNativeQuery instead?
> (https://coderanch.com/t/591607/databases/Mapping-JPA-Entity-View)
> - Can create additive schema migrations but not ones that remove
> columns/tables
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
