Fix Exiftool migration id #763
No reviewers
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#763
Loading…
Reference in a new issue
No description provided.
Delete branch "Oneric/akkoma:fix-migration-timeline-exifdesc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
See #744 (comment)
Applying works fine with a 20220220135625 version, but it won’t be
rolled back in the right order. Fortunately this action is idempotent
so we can just rename and reapply it with a new id.
To also not break large-scale rollbacks past 2022 for anyone
who already applied it with the old id, keep a stub migration.
@ -1,37 +1,10 @@
defmodule Pleroma.Repo.Migrations.UploadFilterExiftoolToExiftoolStripMetadata do
defmodule Pleroma.Repo.Migrations.UploadFilterExiftoolToExiftoolStripMetadataStub do
gonna be pedantic
the filename should match the module name
also also, this filename causes migrations to fail from older versions - it works from current dev/stable, but not before
running
causes this to succeed
good catch! If filenames can become important though, it’s probably safer to leave the original filename as is. So the 2022 version now keeps its name and module and filename of the 2024 are now changed to include a
_real
/Real
suffixmigrations from 3.12.2 now work for me
905cbc6d60
to5256678901
indeedy they do :nod:
thankies