Better document database differences for Pleroma migrations #699
No reviewers
floatingghost
Labels
No labels
approved, awaiting change
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our 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!699
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Oneric/akkoma:doc_pleroma-migration-db"
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?
As a followup to #684 and AkkomaGang/landing-site#11
I did not attempt to actually perform a migration to Akkoma and back to Pleroma, but given I (should have) only rearranged existing instructions and added an additional backup step, this hopefully shouldn’t be any less good than before.
some small nits
@ -24,0 +25,4 @@As time goes on Akkoma and Pleroma added or removed different featuresand reorganised the database in a different way. If you want to be able tomigrate back to Pleroma without loosing any affected data, you’ll want tospelling,
losing@ -24,0 +39,4 @@back to Pleroma or future Akkoma upgrades might affect them, so perhaps back them up as well:- the `birthday` of users and their `show_birthday` setting- the `expires_at` at key of in the `user_relationships` tableshould that
atbe there?nope, removed it; thx
91542d214e18d8d3339f18d8d3339fbff2812a93Updated to reflect both already store instance metadata albeit slightly differently, as noted in #225 .
Not sure if the different timestamp type will cause migration issues in one or both directions.
all good, thankies