Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Date Migrations for SQLite & PG when using UTC #7351
We have had a couple of bugs reported which are in fact a symptom of an issue with the Date migrations we did in Ghost 0.9.
We have identified a logic mistake which means that dates are not in the right format in sqlite3 and postgres if your server was running in UTC when the migration ran.
This mistake will be corrected with a 008 migration, and shipped as 0.11.0.
added a commit
Sep 14, 2016
@ScottHelme, You need to export your data from /ghost/settings/labs/ first, then transform, and import the transformed JSON file.
Since #4685 has not been implemented (2 years), you have to delete all content before importing the data, while try ignore the result of all post id growth (backup your ghost.db first).
I have a solution, which i've tested together with @ScottHelme .
Write me a direkt message in slack if you have problems!
It's great that we have figured out the cause and a workaround. The question now is, what to do to try to get everyone's data back into a consistent state?
First things first, lets fix the migration for 0.11.1 so that anyone upgrading through won't encounter the problem. I'm not sure what the correct fix is though, ideally we'd only migrate dates that haven't been upgraded. I'm not sure if testing based on the settings.dbHash would be a safer guard, or if we should have stuck with the original check for UTC?
Secondly we handle people who are on 0.11 already. I see a couple of options:
These all have different up/downsides. The first option is manual, which is just a bit rubbish when we've always done automatic migrations in the past. The second option is a bit of a hack which circumvents our versioning, however it will target only affected people. The third option is possibly the "right way" but also is going to be tricky, I think, to detect what state people are now in and guarantee correctness.
Therefore, I'm leaning towards 2. Fix the migration so that it always works then add an extra line to the bootup to detect anyone that's already on version 008, maybe check if their migration is correct and rerun the migration if not or else (if it's safe to run), run it anyway.
I would like to suggest something slightly different:
So i will re-write the
@ErisDS what do you think?