a2330ce2d5
This is one requirement in bringing #15 to reality. Currently there are some 450 migration scripts that have been added over the past 11 years. Unfortunately some of these migration scripts have some defects. Either from the fact that they are very old and from another database engine (MySQL vs currently MariaDB), make assumptions about the database name, or its contents. Due to these defects trying to bring an empty schema up-to-date by running all migrations will fail with [372](ff4c5b58b4/core/src/main/resources/db/migration/V372__update_and_insert_grading_criterion_template_master.sql
) being the main blocker. If it is not possible to bring an empty schema up-to-date it is a major hindrance to the plan of automatically deploying test servers for every pull request (#15). These changes makes it possible to bring an empty schema up to the latest version by squashing all migration scripts to a single new baseline with the necessary fixes to work on an empty schema. There is a downside with the way it accomplishes this, it requires any non-empty schema to already be at version [392.2](ff4c5b58b4/core/src/main/resources/db/migration/V392_2__reflection_comment_by_supervisor.sql
). [Flyway](https://www.red-gate.com/products/flyway/), the product we use for database migrations, does not support new baseline scripts in the free version, only in the paid edition. To get around this, Flyway is tricked into thinking the database has never used Flyway before by changing which database table stores the information about applied migrations. This is the reason the database has to be at the latest (392.2) version before deploying the new version of SciPro that include this change, because Flyway will have no way to see which of the old migrations have been applied. An alternative would be to fix the old migrations so they would work on an empty schema. However, since every migration script is checksummed to see that the applied version is the correct one every database would have to be ["repaired"](https://documentation.red-gate.com/fd/repair-184127461.html) to update its checksums. This choice was not taken for two reasons: * It would require manual work in the database before deploying the new version of SciPro with the fixed migrations, similar to the requirement to first deploy the version of SciPro that includes the 392.2 migration. * Running all the migrations taken a lot of time, especially the new [391](ff4c5b58b4/core/src/main/resources/db/migration/V391__harmonize_table_attribute_name.sql
). Squashing all migrations avoid this and makes spinning up new databases very quick ## How to test with an existing schema 1. Deploy commit [ff4c5b58b40db5fcb7754c259c3854194668c1e1](ff4c5b58b4
) (current `develop` branch as of 2024-11-22) 2. Start the system to apply migrations up to and including 392.2 3. Switch to this branch 4. Start the system and see that the database will be considered baselined at version 2 5. Click around in the system and see that it still works ## How to test with an empty schema 1. Empty your database schema 2. Switch to this branch 3. Deploy the system 4. See that it migrates the schema and creates all the necessary tables 5. Log in as `admin@example.com` that is created by the `DataInitializer` Reviewed-on: #24 Reviewed-by: Tom Zhao <tom.zhao@dsv.su.se> Co-authored-by: Andreas Svanberg <andreass@dsv.su.se> Co-committed-by: Andreas Svanberg <andreass@dsv.su.se>
Working with the API
The API is protected by OAuth 2 acting as a resource server verifying tokens using token introspection.
When developing it uses a locally running instance of an
authorization server
that is run inside Docker. It can be started with docker compose -f docker-compose.yml up
.
Since there is no frontend to interact with the authorization server there's a helper script in
GetToken.java that can be run directly with java GetToken.java
to run through the authorization flow
and get an access token.
Once the token has been obtained go to the Swagger UI to interact with the API. Click the "Authorize" button in the top right and paste the access token to log in.
Description
Languages
Java
91%
HTML
8.6%
CSS
0.3%
JavaScript
0.1%