We need to use the existing user from the DB to avoid overwriting the
user's secret or other details.
We also can't assert the user will stay the same, because at least
their name is allowed to change.
The UI should be built and served separately, not from within the
production container.
The tests should be run separately as well and are not needed from
within the production container.
When the import process finishes it can set progress to 100 multiple
times. The first call would add a stop time to the running progress,
but each further call with progress=100 would create another entry in
the table with stop already set.
This includes the code files in the docker image and creates a separate
data dir, which means we don't need to manually mount files into the
container anymore.
Removing the transaction will allow other (async) operations to succeed
while the import is running, otherwise the database will be locked.
It also actually speeds up the import process, and there's no good
reason to roll back if the import aborts mid run.
The two routes offer reloading the whole movie database from IMDb, and
reloading all users' IMDb ratings.
These functions (or very similar) were already available using the CLI,
but now they can be triggered remotely by an admin.
Any field marked as Relation is ignored by all model operations (like
converting to and from plain form). Fields marked as Relation are
meant to store the actual model data for foreign keys stored on the
model.
This includes the patches to get from the initial version of the
database to its current state - for the purpose of documentation.
Beware, if you already have an existing database, running this code
will likely result in an error and/or lead to some minor data loss.
You need to follow these steps to fix your DB:
1. delete all *.sql files from unwind/sql/
2. remove the .disabled suffix from unwind/sql/00000001-fix-db.sql.disabled
3. start the application once, this will fix up the database
4. revert all changes to unwind/sql/ – or leave it, it doesn't matter.
The vast majority of time was spent loading each movie individually.
We always need to load every movie to check if it needs updating, or
if it maybe doesn't exist yet. We can drastically increase performance
by loading the movies in large batches.
- Postpone setting an ID for a Movie until it's added to the database.
- Use larger chunks to count the lines of an input file.
- Skip creating temporary objects for the score-map.
