skorotkiewicz/rDrama
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Minor README tweaks.

Browse source
This commit is contained in:
Ben Rog-Wilhelm 2023-02-12 19:48:25 -06:00
parent efa722b676
commit 0f1bd0ff1a
1 changed files with 10 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

16
readme.md
View file

@ -11,13 +11,17 @@ On Windows, Docker will pester you to pay them money for licensing. If you want
2 - Install [Git](https://git-scm.com/). If you're on Windows and want a GUI, [Github Desktop](https://desktop.github.com/) is quite nice.
3 - Run the following commands in the terminal:
3 - Run the following commands in the terminal or command line for first-time setup:
```
```sh
git clone https://github.com/themotte/rDrama/
cd rDrama
```
4 - Run the following command to start the site:
```sh
docker-compose up --build
```
@ -41,11 +45,11 @@ Database migrations are instructions for how to convert an out-of-date database
## Why use database migrations
Database migrations allow us to specify where data moves when there are schema changes. This is important when we're live -- if we rename the `comments.ban\_reason` column to `comments.reason\_banned` for naming consistency or whatever, and we do this by dropping the `ban\_reason` column and adding a `reason\_banned` column, we will lose all user data in that column. We don't want to do this. With migrations, we could instead specify that the operation in question should be a column rename, or, if the database engine does not support renaming columns, that we should do a three-step process of "add new column, migrate data over, drop old column".
Database migrations allow us to specify where data moves when there are schema changes. This is important when we're live -- if we rename the `comments.ban_reason` column to `comments.reason_banned` for naming consistency or whatever, and we do this by dropping the `ban_reason` column and adding a `reason_banned` column, we will lose all user data in that column. We don't want to do this. With migrations, we could instead specify that the operation in question should be a column rename, or, if the database engine does not support renaming columns, that we should do a three-step process of "add new column, migrate data over, drop old column".
## Database schema change workflow
As an example, let's say we want to add a column `is\_flagged` to the `comments` table.
As an example, let's say we want to add a column `is_flagged` to the `comments` table.
1. Update the `Comment` model in `files/classes/comment.py`
```python
@ -62,7 +66,7 @@ As an example, let's say we want to add a column `is\_flagged` to the `comments`
./util/command.py db revision --autogenerate --message="add is_flagged field to comments"
```
This will create a migration in the `migrations/versions` directory with a name like `migrations/versions/2022\_05\_23\_05\_38\_40\_9c27db0b3918\_add\_is\_flagged\_field\_to\_comments.py` and content like
This will create a migration in the `migrations/versions` directory with a name like `migrations/versions/2022_05_23_05_38_40_9c27db0b3918_add_is_flagged_field_to_comments.py` and content like
```python
"""add is_flagged field to comments
Revision ID: 9c27db0b3918
@ -82,7 +86,7 @@ def downgrade():
op.drop_column('comments', 'is_flagged')
```
3. Examine the autogenerated migration to make sure that everything looks right (it adds the column you expected it to add and nothing else, all constraints are named, etc. If you see a `None` in one of the alembic operations, e.g. `op.create\_foreign\_key\_something(None, 'usernotes', 'users', ['author\_id'])`, please replace it with a descriptive string before you commit the migration).
3. Examine the autogenerated migration to make sure that everything looks right (it adds the column you expected it to add and nothing else, all constraints are named, etc.) If you see a `None` in one of the alembic operations, e.g. `op.create_foreign_key_something(None, 'usernotes', 'users', ['author_id'])`, please replace it with a descriptive string before you commit the migration.
4. Restart the Docker container to make sure it works.