Does Oban have interface for retrieving information about the jobs?

Questions / Help
, ,
1

I want to let the user run customly, statically predefined set of tasks from a web page, as well as view their states, results, possibly errors, arguments, when they were or will be executed…

A task might look like this:

defmodule MyTask1 do
  def run (args) do
  end
end

defmodule MyTask2 do
  def run (args) do
  end
end

defmodule MyTask3 do
  def run (args) do
  end
end

On a page “new task” I’d then show the user a dropdown with MyTask1, ...3 and a button “run”. And on a page “list user’s tasks”, I’ll show him all the tasks created by HIM: the likes of their statuses, buttons to manage them (terminate, for instance), inserted_at, result…

Think of them as “spider tasks” – for site1, site2, site3…
“download tasks” – for youtube, vimeo, vk…
or anything similar.

Let’s say, I planed to use Oban to power this. I’d then also need almost all the information that Oban keeps in the oban_jobs table – to show the user on a page. Additioanally, I’d need to be able to retrieve only the jobs of a particular user rather than all ones in the table.

Does Oban have interface for retrieving the information about the jobs at all? If so, how would I do this?

Otherwise, what would be a way to retrieve it? By SQL, directly from the table?

1 Like
2

Hey @OrontaMedu at a high level you can simply Oban.Job |> Repo.get(job_id) and query voila, you’ve got all of the relevant information.

That said, if you find yourself needing to modify the oban_jobs table to do things like store a user_id I would strongly suggest doing your own modeling around users and tasks, and then having those track which oban jobs are relevant. The oban_jobs table can see a lot of load and it is not optimal to use as both a canonical store of user related information AND a job queue.

3 Likes
3

I’ll create my own table – user_jobs (some_fields, ......., user_id, oban_job_id)

4

Yea I think that’s a great idea. This way you can also delete the actual oban job after a while (via the pruner) to keep that table small and performant. I’d make sure to denormalize any data you want to keep for the long term in your user_jobs table.