Welcome to the first day of Pro v1.5 Launch Week!
Throughout the week we’ll be highlighting and demoing our favorite features of this upcoming release. We got carried away with this Pro release, and there’s far too much to pack into a single announcement.
As you’ll see over the course of the week, it’s a paradigm shift for Oban Pro that opens up the way you write workers, configure queues, and compose jobs. Check back daily as we unroll this behemoth of a release.
Unified Migrations
Oban has had centralized, versioned migrations from the beginning. When there’s a new release with
database changes, you run the migrations and it figures out what to change on its own. Pro behaved
differently for reasons that made sense when there was a single producers table, but it doesn’t
track with multiple tables and custom indexes.
We’ve solved that problem.
Now Pro has unified migrations to keep all the necessary tables and indexes updated and fresh, and you’ll be warned at runtime if the migrations aren’t current.
Here’s an example of the migration experience:
Chained Jobs
Switching workflows from reactive to preemptive, where jobs won’t execute until they’re ready, was a massive speed boost in Pro v1.4. Afterwards we thought, “aren’t chains really infinite linear workflows with automatic links between jobs?” Let’s do the same thing for chains!
Much easier said than done, but absolutely worth it (we’ll spare you the hours of discussion we had about this in the heat). Preemptive chaining doesn’t clog queues with waiting jobs, and it chews through a backlog without any polling.
Chains are also a standard Oban.Pro.Worker option now. There’s no need to define a chain
specific worker, just add the option and you’re guaranteed a FIFO chain of jobs.
Take a look at how easy it is to chain jobs:
This is the first of several changes to workers that open up job composition possibilities. We’ll have much more on that later 😉.
Worker Aliases
Module names change as applications grow, and workers are no exception. Renaming a worker module when there are jobs queued up causes a flood of failing jobs, and it’s a common foot gun.
Worker aliases solve the perennial issue of breaking existing jobs when workers are renamed.
Check it out:
It’s a small quality of life feature, but one we’re sure will help teams grow their Oban powered applications.
More Launch Week
- Day 2 — Enhanced Uniqueness and Distributed PostgreSQL
- Day 3 — Job Decorators
- Day 4 — Overhauled Batches and Improved Workflows
- Day 5 — Hybrid Compositions and Release Day
Meet us back here tomorrow!
As usual, if you have any questions or comments, ask in the Elixir Forum or the #oban channel on Elixir Slack. For future announcements and insight into what we're working on next, subscribe to our newsletter.