fix: confine all objects to the apalis schema (#86)#89
Conversation
|
You cannot modify migrations directly since this would break for existing
users.
…On Thu, 4 Jun 2026 at 20:06, Ty Larrabee ***@***.***> wrote:
@tysen <https://github.com/tysen> requested your review on:
apalis-dev/apalis-postgres#89
<#89> fix: confine all
objects to the apalis schema (#86
<#86>) as a code
owner.
—
Reply to this email directly, view it on GitHub
<#89?email_source=notifications&email_token=AWXVRGSFXRERSUV24OGY65346GUBZA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTENRTGQ4DAMZRG4YDJJTSMVQXG33OWBZGK5TJMV3V64TFOF2WK43UMVSKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#event-26348031704>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWXVRGQHYAYRKMMSXZ2XST346GUBZAVCNFSM6AAAAACZ2VLV5GVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMRWGM2DQMBTGE3TANA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
Move the objects apalis creates out of `public` - generate_ulid() becomes apalis.generate_ulid() and no longer depends on pgcrypto -- its 10 random bytes come from core gen_random_uuid() instead of pgcrypto's gen_random_bytes(). A new forward migration creates it, repoints the legacy (driver-unused) apalis.push_job at it, and drops public.generate_ulid. - The sqlx migrations table moves from public._sqlx_migrations to apalis._sqlx_migrations via a new sqlx.toml (requires sqlx 0.9). This also isolates apalis's migration history from a user's own sqlx migrations, which previously collided over the shared default table name. - pgcrypto is no longer used; it is left where an earlier version installed it and documented as droppable. The upgrade is automatic and non-breaking. PostgresStorage::setup() relocates an existing apalis-owned public._sqlx_migrations into the apalis schema and re-stamps checksums (read from the embedded migrator) before running migrations, so existing deployments migrate with no manual steps and nothing is re-run. The relocation is guarded so it never adopts a user's own public._sqlx_migrations sharing the default name. The only edited migration is the first one (CREATE SCHEMA -> CREATE SCHEMA IF NOT EXISTS, so create-schemas can pre-create the schema on fresh installs); its checksum is healed by the same transition. Also bumps sqlx 0.8 -> 0.9 (remapping the runtime/TLS cargo features that 0.9 split apart) and updates deny.toml / cargo-vet for the new dep tree.
tysen
force-pushed
the
fix/confine-to-apalis-schema
branch
from
b4c57bb to
513c73b
Compare
| /// The move is guarded so it never adopts a `public._sqlx_migrations` that | ||
| /// belongs to a user's own sqlx migrations sharing the default name. | ||
| #[cfg(feature = "migrate")] | ||
| async fn relocate_legacy_migrations_table(pool: &PgPool) -> Result<(), sqlx::Error> { |
There was a problem hiding this comment.
I think rather than doing this, why not use sqlx migrations? I am not sure why we need to have a special function to handle this as its not an edge case. Migrating a past migration is a big no no.
| @@ -1,4 +1,4 @@ | |||
| CREATE SCHEMA apalis; | |||
| CREATE SCHEMA IF NOT EXISTS apalis; | |||
There was a problem hiding this comment.
You cannot directly modify migrations. This would break anyone already with this migration. Is there a specific reason you need to do this?
|
The accidental pollution of the I think you have an opportunity with your impending 1.0 release to make a breaking change and clean this up - this PR does so. The We have to edit the first migration because of the missing We can't use an |
2 participants
Fixes #86
Every object apalis creates now lives in the
apalisschema:generate_ulid()is created asapalis.generate_ulid()with a pinnedSET search_path = apalis, public, so its baregen_random_bytes()call resolves whether pgcrypto is installed intoapalis(fresh DBs) or already exists inpublic.pgcryptois installed withSCHEMA apalison fresh databases.apalis._sqlx_migrationsvia a newsqlx.toml(create-schemas+table-name), which requires sqlx 0.9. The first migration'sCREATE SCHEMAis nowIF NOT EXISTSto coexist withcreate-schemas.Also bumps sqlx 0.8 -> 0.9 and remaps the runtime/TLS cargo features (0.9 removed the combined
runtime-*-tlsflags), regenerates the.sqlxoffline cache, and updatesdeny.toml/ cargo-vet exemptions for the new dependency tree.BREAKING CHANGE: existing pre-1.0 deployments track migrations in
public._sqlx_migrations; after this change sqlx looks inapalis._sqlx_migrationsand will try to re-run every migration. Recreate theapalisschema (and droppublic._sqlx_migrations) when upgrading.