da592558c2
!!! Please merge AFTER #20723 for migrate version (this PR is set up to seamlessly be merged after that PR) !!! Adds a new option to character preferences determining whether a shell is a hidden shell or not. Right now this is a Yes/No toggle that solely makes records display as "Human" instead of "Shell Frame". The previous iteration of this was icky.  I hope this is better. My rationale for this is twofold: Right now, you can only play a hidden shell "correctly" if you're untagged. Firstly, this isn't explained anywhere, so people might miss this by playing a tagged shell that's playing human. Someone might do this because a tag can be a potent story tool, especially for specific brands or lines of shells. Imagine tag scanning a runaway you've found and getting presented with `HLTD-S07U24`, suddenly you get a huge amount of storytelling there that wouldn't be present without the tag. <sub>any similarities to persons living or dead is purely coincidental.</sub> Secondly, it also means you can't play a shell who doesn't try and hide it, but also has no tag, because that'll automatically show as human, which is problematic in many ways. Also, I moved the "species" field in records to the top with the rest of the public info, and took it out of employement records, because security and medical would definitely also get that info, logically speaking. In the future (with lore team approval) i would like to enable certain human citizenships for shells with this preference enabled (likely just Sol, but i mean if lore team wants we can get wacky with Dominia too), but that's out of scope for this PR.
Compacted Migrations
To decrease the runtime of the migration unit test, the database migrations will be compacted into a single migration on a regular base. In order to do so, a new "migrate-VERSION" subfolder is created. The initial migration in these subfolders is always a migration with the current db-schema as of the current PR.
In addition the flayway.conf file in the root of the project is updated to use the new migration folder and create a new schema history table (that tracks the applied migrations).
How does this impact you?
If you set up a new database:
Make sure to use the latest migration folder, it will contain everything needed to create a "fresh" database.
If you have a existing database:
Update to the latest migration in the migration folder that you have used so far.
Then switch to the next migration folder (and a new schema version table)
You should use flyway with -baselineVersion="1" baseline instead of the usual migrate for the initial migration
As usual, always make sure that you have a backup and test it first on a non-production copy
Prerequisites
The server connects to a mysql-compatible server (mysql, mariadb, percona), so you'll need one of those with a database and user/password pair ready.
We use flyway to manage database migrations. To set up the database, you'll need to download flyway.
You'll also need some proficiency with the command line.
Attribution
Credit to Mloc from Baystation12 for the initial readme.
Creating migrations
As a coder, creating migrations is relatively easy. And they're a lot more flexible than just updating the initial schema would be.
First, figure out the changes you need to make. From table alteration and creation commands, to simply update and insert statements.
Write them into a .sql file in the SQL/migrate folder, in a valid order of execution. Name the file in the following format:
Vxxx__Description_goes_here.sql
Where xxx is the next version number from the last existing file (include the 0s), and the descrption is a short description for the migration, with spaces replaced by underscores.
Push this to your branch, and you're done!
Initial setup
In the root project directory, run:
path/to/flyway migrate -user=USER -password=PASSWORD -url=jdbc:mysql://HOST/DATABASE
Where USER is your mysql username, PASSWORD is your mysql password, HOST is the hostname of the mysql server and DATABASE is the database to use.
Migrating
Use the same command as above. Handy, isn't it?
Using a pre-flyway database
Note that this is not recommended! You may run into issues with some migrations, due to improper versioning. The best way to utilize this system is to set everything up on an empty schema. The next alternative is to make sure your database structure matches the V001 file within the migrate folder by manually modifying the structure to avoid dataloss, and then doing the steps described below.
If you're using a database since before we moved to flyway, it's a bit more involved to get migrations working.
In the root project directory, run:
path/to/flyway baseline -user=USER -password=PASSWORD -url=jdbc:mysql://HOST/DATABASE -baselineVersion=001 -baselineDescription="Initial schema"
From there, you can run migrations as normal.
Configuration file
Instead of putting -user, -password and -url in the command line every time you execute flyway, you can use a config file. Create it somewhere in the root of your project (we're calling it 'db.conf'):
flyway.url=jdbc:mysql://HOST/DATABASE
flyway.user=USER
flyway.password=PASSWORD
Now you can just run flyway migrate -configFile=db.conf, and the settings will be loaded from config.
Misc tables
We included a set of miscellanious tables in the misc folder. These are primarily used for debugging and are not meant to be pushed into production. As such, they're not included in the migration folder.
Ignoring or implementing them should not cause issues with the system.