Bulk delete and run immediately

[statianzo]

trafficstars

Right now if you want to remove 5 jobs, you have to click 5 trash cans. We should be able to select jobs via checkbox and perform an action.

[ericboehs]

Taking a quick look, we'd need to:

• [ ] Add SQL[:delete_jobs] and SQL[:reschedule_jobs] in lib/que/web/sql.rb. I'd assume these would take an array of ids.
• [ ] Implement delete and put actions for the 3 job states: running, scheduled and failing (e.g. delete "/failing" and a put "/failing"). They would go around here (or perhaps after the corresponding get).
• [ ] These actions wouldn't be able to use the currently existing SQL queries (e.g. SQL[:failing_jobs]) unless we only supported "Delete all on this page" (it appears the statements require page size and offset as arguments). New statements (e.g. SQL[:failing_jobs_all]) for each job state filter would need to be created. The paginated and unscoped statements could probably be DRYed together.
• [ ] These filtered requests would then take the ids from the new unpaginated statements (e.g. SQL[:failing_jobs_all]) and pass them to SQL[:delete_jobs]. This would be non-iterative so as to only use 2 sql queries (e.g. DELETE ... WHERE id in (1, 2, 3,...)). I'm not sure if the current SQL[:delete_jobs] syntax supports that so a new statement may be needed there too.

Overall this feature would take a few hours to implement especially with the proper tests. Fortunately it's primarily a backend job so no new HTML or CSS is needed (besides the delete button). Unfortunately I don't have enough time or need of this feature to implement it myself.

I hope my quick thinking through this helps someone implement this feature. I'd love to see it in my /que.

[statianzo]

I agree that it's low hanging fruit. Thanks for the task list, @ericboehs.

[joevandyk]

Seems like it would be simplest to just change the http endpoint to accept an array job ids, then delete the jobs one at a time inside a transaction.

[ericboehs]

I thought about that but I have several thousand jobs and I don't think that be very performant.

[statianzo]

We'd want two different endpoints, "delete" and "delete_all". "delete" could take an array of ids, and "delete_all" would perform an sql delete without an id filter. With "delete" alone, we'd have to pass down potentially several thousand ids to the client on any given page.