Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct upgrade from 0.7.x -> 0.10 does not work #7297

Closed
ErisDS opened this issue Aug 31, 2016 · 4 comments
Closed

Direct upgrade from 0.7.x -> 0.10 does not work #7297

ErisDS opened this issue Aug 31, 2016 · 4 comments

Comments

@ErisDS
Copy link
Member

ErisDS commented Aug 31, 2016

In the past, we have been pretty good at supporting upgrades from any version to any version. However, we do state in the docs that minor updates should be done one-at-a-time (see here).

Currently, when upgrading from 0.7.x -> 0.10 you'll see the following errors:

Migrations: Creating database backup

ERROR: select count(distinct posts.id) as aggregate from "posts" where "posts"."visibility" = 'public' and "posts"."page" = true and "posts"."status" = 'published' - SQLITE_ERROR: no such column: posts.visibility 

Error: select count(distinct posts.id) as aggregate from "posts" where "posts"."visibility" = 'public' and "posts"."page" = true and "posts"."status" = 'published' - SQLITE_ERROR: no such column: posts.visibility 
at Error (native)

I believe that this is caused by the sitemap trying to generate when Ghost boots into maintenance mode whilst the migrations run. This is an oversight, as the API calls should fail (but don't because they are internal rather than HTTP which triggers the middleware). The updates to the sitemap to use visibility in 0.10 are the reason why this is suddenly causing a problem and wasn't before. The sitemap should not initialise until after maintenance mode is finished.

I am not sure that this is a bug that warrants fixing. The workaround is to properly upgrade through the minor versions, from 0.7.x to 0.8 and then 0.9 and 0.10. This is a pain, but we are already working on alternative upgrade strategies for the future. For now, this is probably worth a short investigation to see if there is a quick fix.

@kirrg001
Copy link
Contributor

kirrg001 commented Sep 2, 2016

will look into quickly

@kirrg001
Copy link
Contributor

kirrg001 commented Sep 2, 2016

as @ErisDS has guessed, sitemap generation requests the database before the migration has finished. will create a PR with a fix on sunday/monday. sorry for trouble!

@fxlv
Copy link

fxlv commented Sep 3, 2016

Just hit this exact problem when upgrading from 0.7.1 to 0.10.
As a workaround, upgrading 0.7.1 -> 0.9.0 -> 0.10 worked for me.

@ErisDS
Copy link
Member Author

ErisDS commented Sep 3, 2016

Just to reiterate, our official recommendation is always to upgrade through each minor version one at a time (so 0.7.1 -> 0.8 -> 0.9 -> 0.10)
Even more importantly, it is recommended to manually run Ghost using npm start --production the first time, so that you can monitor the progress of each upgrade.

kirrg001 added a commit to kirrg001/Ghost that referenced this issue Sep 5, 2016
closes TryGhost#7297
- move sitemap initialisation into sitemap handler
- initialise sitemap on first request to sitemap
@ErisDS ErisDS closed this as completed in 2142a9c Sep 6, 2016
mixonic pushed a commit to mixonic/Ghost that referenced this issue Oct 28, 2016
…7320)

* 🐛 fix direct update

closes TryGhost#7297
- move sitemap initialisation into sitemap handler
- initialise sitemap on first request to sitemap

* 🐛 fix how we pass options to migration files

refs TryGhost#7317
- clone options when passing them into the migration/fixture files
- do not use default sequence, because it does not clone the arguments
geekhuyang pushed a commit to geekhuyang/Ghost that referenced this issue Nov 20, 2016
…7320)

* 🐛 fix direct update

closes TryGhost#7297
- move sitemap initialisation into sitemap handler
- initialise sitemap on first request to sitemap

* 🐛 fix how we pass options to migration files

refs TryGhost#7317
- clone options when passing them into the migration/fixture files
- do not use default sequence, because it does not clone the arguments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants