abdab7a0a8
Rework the upload process so that files are saved to Danbooru first before the user starts tagging the upload. The main user-visible change is that you have to select the file first before you can start tagging it. Saving the file first lets us fix a number of problems: * We can check for dupes before the user tags the upload. * We can perform dupe checks and show preview images for users not using the bookmarklet. * We can show preview images without having to proxy images through Danbooru. * We can show previews of videos and ugoira files. * We can reliably show the filesize and resolution of the image. * We can let the user save files to upload later. * We can get rid of a lot of spaghetti code related to preprocessing uploads. This was the cause of most weird "md5 confirmation doesn't match md5" errors. (Not all of these are implemented yet.) Internally, uploading is now a two-step process: first we create an upload object, then we create a post from the upload. This is how it works: * The user goes to /uploads/new and chooses a file or pastes an URL into the file upload component. * The file upload component calls `POST /uploads` to create an upload. * `POST /uploads` immediately returns a new upload object in the `pending` state. * Danbooru starts processing the upload in a background job (downloading, resizing, and transferring the image to the image servers). * The file upload component polls `/uploads/$id.json`, checking the upload `status` until it returns `completed` or `error`. * When the upload status is `completed`, the user is redirected to /uploads/$id. * On the /uploads/$id page, the user can tag the upload and submit it. * The upload form calls `POST /posts` to create a new post from the upload. * The user is redirected to the new post. This is the data model: * An upload represents a set of files uploaded to Danbooru by a user. Uploaded files don't have to belong to a post. An upload has an uploader, a status (pending, processing, completed, or error), a source (unless uploading from a file), and a list of media assets (image or video files). * There is a has-and-belongs-to-many relationship between uploads and media assets. An upload can have many media assets, and a media asset can belong to multiple uploads. Uploads are joined to media assets through a upload_media_assets table. An upload could potentially have multiple media assets if it's a Pixiv or Twitter gallery. This is not yet implemented (at the moment all uploads have one media asset). A media asset can belong to multiple uploads if multiple people try to upload the same file, or if the same user tries to upload the same file more than once. New features: * On the upload page, you can press Ctrl+V to paste an URL and immediately upload it. * You can save files for upload later. Your saved files are at /uploads. Fixes: * Improved error messages when uploading invalid files, bad URLs, and when forgetting the rating.
Jobs
This directory contains background jobs used by Danbooru. Jobs are used to handle slow-running tasks that need to run in the background, such as processing uploads or bulk update requests. They're also used for asynchronous tasks, such as sending emails, that may temporarily fail but can be automatically retried later.
Jobs use the Rails Active Job framework. Active Job is a common framework that allows jobs to be run on different job runner backends.
In the production environment, jobs are run using the Good Job backend. Jobs
are stored in the database in the good_jobs table. Worker processes spawned
by bin/good_job poll the table for new jobs to work.
In the development environment, jobs are run with an in-process thread pool. This will run jobs in the background, but will drop jobs when the server is restarted.
There is a very minimal admin dashboard for jobs at https://danbooru.donmai.us/jobs.
Danbooru also has periodic maintenance tasks that run in the background as cron jobs. These are different from the jobs in this directory. See app/logical/danbooru_maintenance.rb.
Usage
Start a pool of job workers:
RAILS_ENV=production bin/good_job start --max-threads=4
Examples
Spawn a job to be worked in the background. It will be worked as soon as a worker is available:
DeleteFavoritesJob.perform_later(user)
See also
- app/logical/danbooru_maintenance.rb
- app/controllers/jobs_controller.rb
- config/initializers/good_job.rb
- test/jobs